Могут ли юнит тесты находить функциональные баги
Что проверяют
Понимаете ли вы, что уровень и тип тестирования это разные оси, и где проходит граница возможностей юнит-тестов. Следом обычно спрашивают, как QA может влиять на качество юнит-тестов, которые пишут разработчики.
Как отвечать
Да, могут, но только часть. По ISTQB компонентное тестирование это уровень, а функциональное это тип. Проверка того, что функция делает требуемое спецификацией, и есть функциональный тест, просто на уровне компонента.
Что юнит-тест ловит хорошо:
- бизнес-правила внутри модуля: расчёт скидки, валидация, округление сумм, переходы статусов заказа;
- граничные значения и классы эквивалентности: пустая строка, ноль, максимальная длина, високосный год;
- обработку ошибок: поведение при
null, некорректных данных, исключении зависимости.
Что он не поймает по построению:
- интеграцию: зависимости заменены моками, поэтому неверный контракт с другим сервисом, ошибка маппинга или SQL проходят незамеченными;
- конфигурацию и окружение: переменные, права, часовой пояс сервера, миграции базы;
- сценарий целиком: баг на стыке нескольких экранов или шагов;
- неверное понимание требования: если код и тест писал один человек с одной ошибкой в голове, тест подтвердит баг.
Роль QA здесь конкретная: сверять юнит-тесты с требованиями, подсказывать кейсы из тест-дизайна, оценивать не процент покрытия, а качество проверок. Для этого есть мутационное тестирование: PIT для Java, Stryker для JavaScript и .NET, mutmut для Python. Инструмент вносит мелкие изменения в код, и если тесты остаются зелёными, они ничего не проверяют. Стыки сервисов закрывают контрактными тестами, например на Pact, и интеграционными.
Где спотыкаются
Отвечают «юнит-тесты это зона разработчиков, функциональные баги ищет QA». Звучит как отказ от ответственности и показывает, что вы не видите пирамиду тестирования целиком.
Приравнивают высокое покрытие к отсутствию багов. Тест без проверок даёт 100% покрытия строк и не ловит ничего.
Утверждают обратное: юнит-тесты находят только технические ошибки. Правило, реализованное в одном классе, проверяется юнит-тестом дешевле и быстрее, чем через интерфейс.