mutation{
  addOnCreate(input: {
    clientMutationId: "1234",
    addOn: {
      hostId: "5",
    }
  }) {
    addOn {
      currency,
    },
    clientMutationId,
    errors {
      key,
      message,
    },
  }
}

спасибо большое))) есть от чего оттолкнуться)

Ctrl + space в помощь, оно же подсказывает куда и что можно писать

дада) я просто не догнал, что clientMutationId и addOn это данные, которые нужно на вход дать

Дисклеймер:
1) список, конечно же, заангажирован.
2) и, разумеется, неполон: что-то забуду, где-то появляются новинки, и они имеют значение.

- Английский. Имеет серьёзное значения для поиска материалов уже для обучения, для работы, гугления, интервью, работы в больших компаниях на заграницу за не самый мелкий прайс.
- По тестированию: Куликова "Тестирование программного обеспечения. Базовый курс." Книга несовершенна, но на интервью не особо больше спрашивают.
- Обязательно надо научиться находить материалы самостоятельно. Не шучу. "Волка ноги кормят", а тестировщика кормит поиск.
- Потратить какое-то время на изучение контроля версий Git. По нему есть бесплатно книга "от производителя", и её достаточно. Неплохо бы понять работу с Git ещё перед тем как приступить к серьёзному кодированию.

Java:
- Если совсем ничего не программировал, то можно базовые курсы, где и какие найдутся. Заграничные есть на Udemy и подобных ресурсах, русскоязычные есть от Алексея Баранцева и прочие "только набери в Гугле"
- Я считаю что неплохой быстрый старт можно взять с Java for Testers of Alan Richardson. Там нужный минимум и примеры кода.
- Из книжек — Клэй Хортсманн, Core Java и продолжение. Там много, но читать это надо.
Начать писать код можно быстрее чем дочитать книжку. У того же Ричардсона есть примеры. В Интернете находится описание по тестированию REST API с Junit, мне нравятся материалы на Youtube из сообщества COMAQA.
Много народу агитирует за RestAssured для проверок по API, но это не единственный инструмент, хотя и популярный.
Попутно можно освоиться с Postman, он не Java, просто подсобник для работы.

Случились интересные качественные изменения в Java 8, которые полезно знать и вообще, и для работы, и для интервью.

Насдирать полным-полно примеров кода для учёбы можно с GitHub, не только с Ричардсона.

Очень рекомендую изучить книжку или видео или хоткеи и их работу по рабочему стандарту-де-факто: IDE IntelliJ IDEA, и работать именно с ней. Написание кода со знанием возможностей IDE -- намного мощнее, как работа  "продвинутого пользователя".

После REST API можно постепенно переходить на Selenium. Но сначала Chrome Developer Tools, локаторы, операции с элементами из консоли.

По Selenium конкретной книги не посоветую, но есть и книги, и видео на Ютубе, и статьи-примеры. Полно примеров от Dave Haeffner, автора дорогущей книги Selenium Guidebook ( которую я, наверное, никогда не куплю за 59 баксов), но за примеры и рассылку автору благодарен. Примеры лежат на сайте Elemental Selenium.

Где-то на этой стадии или чуть пораньше возникнут вопросы насчёт правильности направления. Отдельная категория материалов посвящена, собственно, интервью. Есть сайты-подборки "Интервью Java" и "Интервью Selenium" или "Интервью автоматизатора". Там может быть не всё, там могут быть устаревшие материалы, там может быть что-то нужное только хардкорным разработчикам, но, как говорится, это уже что-то.

В тестировании важно знать не только как надо делать, но и как не надо делать :) Хорошие видео можно найти и по запросам "ошибки (начинающих) автоматизаторов".

Серебряной пули нет. Учить и знать надо много, и _будет_ надо много.
Может всплыть работа в Linux и MacOS, прокси, эмуляторы, виртуализация, Докер с контейнерами, и ещё всякого.
"Большого выбора вакансий" уже просто так не бывает. Чем больше умеешь, тем больше выбор.

добавил ссылку на пост в закреп, потрясающе! спасибо!

кто-нибудь пишет автотесты на mftf???

кто-то пишет. задайте конкретный вопрос

вопросов пока что нету. хотел узнать есть ли такие тут... мне просто скоро прилетит таска на написание тестов... вот тогда будут вопросы(

Это просто шикарно!  Спасибо!
От себя добавлю,  что упираемся в достаточно распространенные проблемы всех новичков:
- тестирование - лучшее для входа в IT;
- тестирование - это просто;
- тестирование - это не про технические знания;
- тестирование - это ... *добавить своё*

Идеальное вхождение в тестирование как мне кажется, может выглядеть так: (при условии большого количества времени и серьезного подхода к обучению)
- Информатика (что такое информация, сообщение, язык, зачем и что это нужно);
- Архитектура вычислительных систем/компьютера ( надо знать как работает инструмент внутри);
- Компьютерные сети (то, что поможет в понимании работы не монолитных приложений);
- Web-технологии( устройство браузера, работа с html/css/js/dom/ etc.)
- Операционные системы и оболочки ( важные знания по windows/*nix и остальным, если нужно будет)
- Технологии разработки ПО (понимание ЖЦПО и процессов)
- Тестирование. Фундаментальные теории.
- Программирование. Теория + практика.

Практика программирования должна быть от 1 года для того, чтобы:
- понимать разработку ПО;
- понимать "язык" разработки;
- тестирование - деструктивный процесс. И он значительно сложнее, чем разработка - процесс созидания;

Таким образом, после такого набора теории и хорошей практики идет выбор:
- Автоматизация;
- Мануал (я бы больше сказал, работа с процессами, коллективом, менеджерские моменты)

Деление настолько глупое, что так нельзя. Однако для новичков пусть будет.

Моё конечное мнение: тестирование систем стоит после разработки систем. И в тестировщики должны выходить люди с хорошим техническим бэкграундом.

- тестирование - деструктивный процесс. И он значительно сложнее, чем разработка - процесс созидания;
вот это очень сомнительный тезис

тестирование аналитический процесс в отличии от синтезирующего в разработке
их нельзя сравнивать - они разные

Да, это ближе наверное к тому, что хотел сказать
К сожалению не силен в подобной терминологии.

Это целая пачка очень интересных вопросов. Которые, сразу должен признать, больше по тестированию, а не автоматизации.

- Времена меняются. Программы без UI "со входом и выходом", алфавитно-цифровым, — классика программ и целая куча до сих пор существующих систем, — это совсем не то что современные программы для планшетов. Большинство книг по тестированию и техник формального тестирования были сделаны для первых.
- 6-12 лет назад "войти в тестирование" правда было куда как проще. Я видел, я знаю.
- Зная сколько того чего знают синьор разработчики не надо знать тестировщикам, легко поверить, и даже обосновать, что войти в тестирование попроще.
- Penetration testing это совсем не то что UI автоматизация. И database testing. И ещё и ещё.
- UX testing или User A/B testing это не REST API автоматизация. Про последнюю Иван Катунов правильно рассказывал что она как раз ближе к формальным техникам. А вот для UX/User testing нужны другие знания, навыки, и умения в вопросы и ответы.
- User testing проводится как раз потому что люди обученные действуют с программами не так как необученные, а необученных пользователей огромные массы. Одно из исследований, к которому я был краем причастен, показало что на экране, который у обученных никаких вопросов и проблем не вызывал, "люди со стороны" могли тупить минуту или больше.
- Классик тестирования Канер делал доклад о том что тестирование это "социальная наука" (кто сталкивался с тем насколько причудливы бывают пожелания клиентов, и как сложно им бывает объяснить реалии проекта, или хотя бы слышал такие истории, может понять).
- Ко мне недавно обращалась практикантка по поводу тестового задания с веб-формой. Формальные техники ей рассказали, про классы эквивалентности и пр. — но чего применять к веб-форме это уже другой вопрос.
- Докладчик Гейзенбага 2019 Питер и инструктор по тестированию с мировой известностью Майкл Болтон может много рассказать что тестирование это не обязательно программирование и технические навыки. Он вообще начинает с того что программирование и тестирование это разные способы думать: "как заставить это работать" и "как это может не работать" + "что может пойти не так",
- Тестирование не деструктивный процесс. Тестировщик тоже, со всей командой, получает денег "от удовлетворения заказчика", а не просто за то что что-то там поломал. Не все мои проекты дошли до релизов, но мне никогда не платили за то "чтобы оно вообще не вышло".
- Тестирование может начинаться со спецификации, оно не обязательно идёт после разработки.
- Если у вас попался очень специфический домен, какая-то сложная аппаратура для специфической области, то человек, разбирающийся в домене, может быть значительно полезнее человека, разбирающегося в формальных техниках тестирования.
_______
Пишу не спора ради, а представления известных мне реалий и точек зрения для. В тестировании специализированных embedded систем и приложений с высокой математикой, высоконагруженных, высокоточных и пр. — действительно нужны люди с хорошим техническим багажом. Но давление сэкономить и нанять людей без такого багажа на рынке очень даже есть, вопросы типа "мне сказали учить ЯП и автоматизировать, что мне делать?" я вижу не только у нас, я их из США в некоторых местах вижу, и не "войти в айти" ради, а "босс решил".
_______
Возвращаясь к автоматизации:
- всего ею не охватишь, в том числе и всего тестирования, про это тоже спрашивают на собеседованиях
- знания, подходы— всё имеет свои ограничения. Хорошо понимать ограничения того чем занимаешься
- у массы явлений есть обратная сторона, Не забывайте что пользователи живые люди, часто нетехнические. Намедни читал историю о том что был низкий conversion rate емнип в Индонезии. Провели исследование. Поле Surname / Фамилия было обязательным, а у них там у значительной части населения не было фамилий. Ну вот "так можно". Для расширения кругозора по похожим темам рекомендуется поиск по Falsehoods programmers believe ...

Спасибо за развернутый ответ! Очень много интересных мыслей на «обдумать»

У каждого свой опыт, свои ассоциации. В моем случае, мнение построенно лишь на собственном опыте перехода из разработчика в тестировщика-автоматизатора.
Безусловно, как и большинство сфер - всё это очень многогранно.
Приятно было прочитать Ваши соображения. Спасибо!

В такие минуты мне кажется, что кого-то сильно печёт, что в тестировщики народ набежал, "понавходили в ИТ через тестирование".

Ввше про рестШарп писали. Он хорош.

У нас на проекте для тестирования апишек родной httpClient используется.
Стек:  nunit 3 + allure + fluentAssertion

Хе-хе наблюдаю такое! Кстати переход из разработки в тестирование я бы считал своим фейлом, поэтому действую в обратном направлении. А многие мои знакомые забили и перешли в аналитику или остались в ручном тестировании с ростом в административную сторону. Полагаю, что разработчик со знанием тестирования и автоматизации является ценным кадром. Надеюсь, со временем смогу данному образу соответствовать)

Ну иногда печалит, что твоя профессия у людей теперь ассоциируется с точкой входа за баблом для всех подряд, и как промежуточная точка на пути к кодерку

А ты госдолг США, в смысле, зарплаты кодерков видел?) Туда и ползут.