С тестированием REST API многие уже знакомы. А что изменится, если мы будем тестировать GraphQL API? Вроде бы и там, и там API, но будет ли чек-лист единым?

В этом докладе мы обсудим:

• Какие принципы тестирования API останутся неизменными.
• Что стоит тестировать в REST, но нет смысла тестировать в GraphQL.
• Что стоит тестировать в GraphQL, но не нужно в REST.

А ещё, конечно же, дам ссылки на тестовые площадки, где можно будет закрепить полученный материал, если на работе пока нет задачи тестировать GraphQL. Но зато, если завтра она вдруг появится, вы будете к ней готовы! =)

Когда наша компания была небольшой, онбординг был очень простой — это Вася / Маша, он(а) тебе всё расскажет и покажет. Но потом команда стала расти, и менторить каждого новичка стало тяжеловато. Это отнимает много времени и сил, да и рассказывать одно и то же по кругу не очень интересно... 

Я расскажу, как мы создавали свой квест для новичков. С чего начинали, что было хорошего и плохого в каждом решении. К чему сейчас пришли и куда будем стремиться в дальнейшем. А заодно подведу итог и дам чек-лист создания такого квеста у себя в команде.

Давайте поиграем в игру — кто напишет меньше тестов, но максимум полезных?) Я подготовила для вас один любопытный примерчик по тестированию REST API. Там и хитрые тесты на логику есть, да и тестирование API никто не отменял. Попробуем написать идеальный чек-лист вместе?) 

Как будет проходить мастер-класс: 

1. Теория 

Я напомню: 

- как тестировать API-методы 

- базу тест-дизайна 

2. Практика 

Я дам ТЗ на метод, который надо проверить. ТЗ будет обрастать подробностями потихоньку: 

- сначала мы проверим базу метода 

- потом докрутим логики 

 Вы обсудите в группе, какие тесты нужны, и сформируете свой список проверок. Потом будем сравнивать результаты: у кого сколько тестов получилось, и каких. Обсудим, что можно выкинуть, а что никак нельзя — и почему!

Что делать, если заказчик нашел ошибку в системе? Воспроизвести локально, написать автотест, отдать разработчику. Вроде несложно. Но что, если у заказчика ошибка есть, а у нас нет? То есть проблема кроется в хитрой комбинации исходных данных. Нужно разбираться, что именно могло повлиять.

Мы прошли длинный путь такой диагностики. Сначала собирали данные через SQL-скрипты, потом автоматизировали их и даже внедрили в систему. А потом упростили задачу разворачивания билда, делегировав это… Телеграм-боту!

Я хочу рассказать вам про наш путь и про то, что вы можете переиспользовать у себя. В докладе вас ждут:

— истории из реальной жизни «споткнулись о проблему — как решали»;

— примеры того, что получалось на каждом этапе;

— исходный код телеграмм-бота, который поднимает докер на виртуалке и запускает в нем сборку maven-a: https://github.com/hflabs/dolores

Знаете ли вы, что такое мнемоники? Какие использовали? Пробовали создавать свои?