Что проверяют юнит тесты
Что проверяют
Понимаете ли вы границу модульного теста и знаете ли, что тестировать не надо.
Как отвечать
Модульный тест проверяет логику одного компонента в изоляции. Всё внешнее подменено: база, сеть, файловая система, текущее время. Отсюда его свойства: выполняется за миллисекунды, не требует окружения, а падение точно указывает на место поломки.
Что именно проверяют:
- результат на разных входах: типичные значения, границы диапазонов, пустые коллекции, ноль, отрицательные числа;
- краевые случаи: то, что ломается чаще всего;
- обработку ошибок: бросается ли нужное исключение, возвращается ли ожидаемая ошибка при некорректных данных;
- инварианты: состояние объекта остаётся корректным после операций;
- взаимодействие с зависимостями там, где оно является требованием: например, что письмо действительно отправляется при подтверждении заказа.
Чего модульные тесты не покажут, и это важно проговорить: правильность запроса к базе, соответствие схемы, ошибку конфигурации, поведение при конкурентном доступе. Тест с подменённым репозиторием проверяет, что заглушка вернула то, что в неё положили, и никакой уверенности в работе с настоящей базой не даёт. Для этого есть интеграционные тесты.
Принципы хорошего теста:
- проверяет поведение, а не реализацию. Тест, знающий, какие внутренние методы вызываются, ломается при любом рефакторинге и мешает вместо помощи;
- детерминированный: никакой зависимости от времени, случайности и порядка выполнения;
- независимый от других тестов;
- читаемый: имя описывает сценарий и ожидание, структура делится на подготовку, действие и проверку.
Что тестировать не стоит: тривиальные методы доступа к полям, чужой код и каркас, сгенерированное. Покрытие при этом растёт, а пользы нет.
Где спотыкаются
Пишут тесты, дублирующие реализацию строка в строку.
Подменяют всё подряд и проверяют работу заглушек.
Гонятся за процентом покрытия.
Считают, что модульные тесты заменяют интеграционные.