К Test Driven Development я отношусь с долей скепсиса. Несколько раз пробовал классический цикл с юнит-тестами и не могу сказать, что мне понравились результаты. Во время реализации я часто находил решение лучше, менял внутренний дизайн и вслед за ним переписывал тесты.
Зато предварительное написание API-тестов показало себя прекрасно. Это не классический TDD, а скорее API-first подход с автоматизированной проверкой контракта.
От Swagger и Postman к автоматическим тестам
Раньше я работал в привычном процессе: код, ручное тестирование через Swagger или Postman, API-тесты в светлом будущем. Затем оказался в команде, где API-тесты сразу пишут сами разработчики.
Поработав в таком окружении, я почти полностью убрал ручную проверку своего кода через Swagger и Postman. Теперь мой процесс выглядит так:
- Пишу спецификацию API. Это недолго, помогает продумать контракт и позволяет заранее отдать его команде на ревью.
- Пишу API-тесты по готовой спецификации.
- Пишу код и сразу проверяю его этими тестами.
На первый взгляд процесс кажется громоздким, но на практике экономит мне время. Особенно заметна разница в сложных сценариях, где нужно сделать несколько вызовов разных API: один раз описанный тест проще и надёжнее повторных ручных прогонов.
Бонусом остаётся набор проверок, который продолжает работать после завершения задачи и страхует последующие изменения.
За удобство нужно заплатить
У подхода есть цена:
- Процесс нужно внедрить в разработку и поддерживать.
- Нужна инфраструктура для удобного запуска тестов.
- Тесты нужно встроить в CI/CD.
- Инфраструктуру и сами сценарии придётся развивать вместе с продуктом.
- API-тесты выполняются дольше юнит-тестов и замедляют пайплайн.
Поэтому я не считаю API-тесты до кода бесплатной серебряной пулей. На маленьком проекте стоимость инфраструктуры может не окупиться. Но в долгоживущем приложении со сложными пользовательскими сценариями этот подход оказался для меня затратным на старте и очень выгодным на дистанции.