Что такое юнит тесты

Что проверяют

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

Как отвечать

Юнит-тест проверяет небольшой участок кода в изоляции от внешнего мира: без базы, сети, файлов и реального времени, всё внешнее заменяется заглушками. Отсюда его свойства: быстрый, повторяемый, независимый от порядка запуска, гоняется на каждое изменение в сборке. Структура простая: подготовили данные, выполнили действие, сверили результат.

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

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

Где спотыкаются

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

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

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