Алгоритм написания автотестов: API

1. Выбрать методы, которые необходимо покрыть автотестами. 

Описать проверки: в зависимости от запроса это может быть как исключительно позитивный сценарий (GET-/DELETE-запросы в REST), так и подборка очень даже необычных вводов и негативных кейсов (например, POST-/PATCH-/PUT-запросы в REST).

2. Написать сценарии тестов, которые планируете автоматизировать, если будет автоматизация e2e через API.

3. Подготовить данные, которые будут использоваться в тестах. Не обязательно на первых этапах, – просто удобно делать это вместе с продумыванием самих проверок.

4. Описать запросы в виде отдельных классов – в зависимости от того, что предполагает выбранный фреймворк/библиотека.

Будет удобнее, если структурно описание запросов будет вынесено из тестов отдельно – ровно как в Page object model для UI мы выносим описание страниц в отдельный класс.

5. Используя классы запросов, написать тесты.

Тест — это метод, в котором выполняются действия и осуществляется проверка. Обычно он сопровождается одноименной аннотацией используемого тест-раннера. Тестов в одном классе может быть несколько. Идеально объединять тесты в класс по логической составляющей: например, позитивные и негативные тесты на авторизацию или на CRUD пользователя.

6. Убедиться, что тесты запускаются и работают. Очевидно, но важно!

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

7. Посмотреть на код тестов и найти повторяющиеся куски. Вынести их в отдельные классы — хэлперы.

Это позволит сократить объем тестового кода и повысить читаемость. Можно начать с того, чтобы просто создать приватный вспомогательный метод внутри тестового класса — потом можно будет вынести его отдельно, если окажется, что он может быть полезен и в других тестовых классах.

8. Посмотреть на код тестов и проверить, соответствует ли он правилам атомарности: 1 тест = 1 проверка.

Например, проверяем метод — значит, валидируем только его, а валидность токена, который нужен для этого метода, проверить лучше в отдельном тесте. Исключение: е2е-сценарии, но это больше про UI, а в API, особенно когда проверяем конкретные методы, лучше придерживаться этого правила. 

9. Проверить, нет ли захардкоженных переменных, констант и вот этого всего. По возможности, данные лучше получать вне теста: например, в TestNg есть аннотация @DataProvider. Также можно использовать Faker'ы – специальные классы, которые рандомно генерируют данные в заданном формате.

10. Проверить, не зависимы ли тесты друг от друга. Можно ли их запускать по отдельности? А параллельно?

11. Проверить, не задевают ли тесты логики других тестов в репозитории. Актуально для случаев, когда мы меняем существующие классы.

12. Отформатировать код по codestyle. Обычно в IDE есть шорткаты на этот случай – отличный повод получше изучить инструмент, с которым работаем.

Также круто проверить, что в коде не осталось комментариев ToDo, ворнингов и ошибок. В этом нам тоже отлично помогает IDE – главное, не игнорировать его сигналы.

13. Проверить, не содержат ли вспомогательные классы assert'ов.

14. Отдать тесты на ревью.

Даже если команда неопытная, не следует пренебрегать ревью. Во-первых, задавая вопросы, коллеги могут натолкнуть автора кода на мысль о том, как можно улучшить уже существующее решение, – бывает, коллективный разум помогает находить баги в коде тестов на этапе статического анализа. Во-вторых, таким образом формируется насмотренность внутри команды, благодаря которой тоже происходит важная часть обучения и обмена знаниями.

В общем, я глубоко убеждена, что код-ревью – для всех, в том числе джуниоров и тех, кто не пишет автотесты.

Призываю к обсуждению: что бы вы добавили, что убрали? Какими лучшими практиками вы пользуетесь, когда пишете автотесты?