Автоматизированное тестирование бэкенда

Бэкенд большинства проектов, которые мы реализуем, существует в формате Rest API. Одна из прелестей такой архитектуры заключается в том, что такой бэкенд можно и нужно покрывать автотестами.

Когда следует покрывать бэкенд автотестами

Всегда. Мы убеждены в этом.

Если архитектура проекта позволяет автоматизировать тестирование бэкенда - нужно автоматизировать, безальтернативно.

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

Из нашей практики, особенно хорошо внедренные автотесты дают о себе знать на проектах, где разработка длится несколько месяцев. На поздних этапах разработки при внедрении нового функционала всё время повышается вероятность "сломать" старый функционал, который был реализован несколько месяцев назад.

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

Мы автоматизируем тестирование бэкенда везде, где позволяет архитектура. Независимо от бюджета на проект.

Как реализуется автоматизированное тестирование

Для автоматизации тестирования бэкенда мы используем PHPUnit. Расскажу в сокращенном виде, как всё работает на примере деплоя на dev-окружение. Для описания в деталях всего процесса, мы подготовим отдельную статью.

При реализации новой функциональности, разработчик самостоятельно пишет и покрывает эту функциональность тестами. Иногда для написания тестов мы дополнительно привлекаем QA - для проработки более широкого набора тестовых данных.

Для автоматизации прогона тестов мы используем функционал CI/CD в GitLab. Тесты запускаются при каждой попытке деплоя. При каждом обновлении код проекта разворачивается на специальном dev-стенде и тесты запускаются на нем.

Если в процессе выполнения тестов произошла ошибка - уведомление моментально прилетает к нам в Slack, его видит вся проектная команда.

Соответственно, если проектная команда видит, что выполнение тестов завершилось с ошибками, то происходит анализ отчета о тестировании (детальные логи также доступны в GitLab) и возникшие ошибки оперативно устраняются.

Таким образом, при реализации каждой новой функциональности регрессионно проверяется весь разработанный ранее функционал. Минимизируется вероятность попадания ошибок на production-стенд. Уменьшается влияние человеческого фактора на процесс разработки.

Не очевидные плюсы автоматизированного тестирования

1. Дополнительный рубеж самопроверки для разработчиков. При написании тестов на собственный функционал, разработчик вынужден взглянуть на него "со стороны", ещё раз проанализировать возможные сценарии его использования.

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

3. Если процессы в команде отлажены - увеличение стоимости разработки несущественно даже в рамках отдельно взятой задачи.

‍