Вот девять распространённых доводов против юнит-тестов и то, как мы должны на них реагировать:
Код слишком простой, чтобы нужны тесты.
Даже простой код может содержать неожиданные ошибки. И что, если код будет развиваться? Он может не оставаться простым навсегда. Как мы вообще можем фактически определить, когда код слишком прост? Если код действительно прост, то написание тестов должно быть быстрым и лёгким, что делает это ещё более оправданным.
Я добавлю тесты позже.
Во многих случаях мы этого не сделаем. Гораздо легче писать юнит-тесты, когда код свеж в нашей памяти. Задержка с написанием тестов показывает проблемное непонимание их истинной ценности. Мы не должны рассматривать их как ограничение, а скорее как преимущество. Тесты — это стратегическая инвестиция в долгосрочное здоровье наших систем.
Тестирование предназначено только для тестировщиков.
Нет, тестирование не предназначено только для тестировщиков. Как разработчики, мы должны убедиться, что наш код работает, прежде чем он будет передан на другие стадии тестирования.
Я однажды работал над проектом, где команда разработчиков считала, что их ответственность состоит только в создании функционала, оставляя все тесты команде контроля качества. Мы проводили лишь минимальное тестирование. В конце концов, у команды оказалось больше тестировщиков, чем разработчиков — явный признак того, что что-то было очень не так. Каждое непрохождение теста занимало гораздо больше времени на исправление, чем если бы у нас были надлежащие юнит-тесты; это было абсолютное бедствие.
Мы остановимся на интеграционных тестах.
Хотя интеграционные тесты важны, они не являются заменой юнит-тестам. Интеграционные тесты, как правило, фокусируются на номинальных случаях и не могут охватывать все крайние случаи. Они также выполняются дольше и могут быть нестабильными. Исправление проблем на этапе интеграционного тестирования обычно занимает гораздо больше времени и сложнее для диагностики, чем юнит-тесты.
Этот код просто временный, поэтому ему не нужны тесты.
Временный код может стать постоянным. Даже если код действительно временный, он всё равно может вызвать серьёзные проблемы, если сломается. Написание юнит-тестов обеспечивает ожидаемое поведение кода во время его временного использования и помогает избежать сбоев, особенно если код останется дольше, чем планировалось.
У меня нет времени на написание юнит-тестов.
Это ложная экономия — ещё один чёткий признак того, что мы не понимаем истинную ценность юнит-тестов. Пропуск юнит-тестов может показаться экономией времени, но часто приводит к более серьёзным проблемам в будущем. Опять же, исправление ошибок, обнаруженных на более поздних стадиях разработки, гораздо более дорогостояще и времязатратно.
У этого кода не было юнит-тестов, так почему начинать сейчас?
Никогда не поздно начать писать юнит-тесты. Использование отсутствия тестов как оправдание — это на самом деле противоположно тому, что мы должны делать. Наша установка должна быть следующей: давайте оставим кодовую базу в лучшем состоянии, чем мы её нашли. Это не означает погашение всех долгов по тестированию сразу, но по крайней мере, это наша ответственность — убедиться, что любые внесённые нами изменения должным образом протестированы. Тем временем, начало с юнит-тестов сейчас может установить новый стандарт качества и задать положительный прецедент для остальной части кодовой базы.
Этот проект — просто PoC; он не выйдет в продакшн.
Хотя проект может быть задуман как просто Доказательство Концепции (PoC), всегда есть шанс, что он может выйти в продакшн — и даже быстрее, чем мы можем себе представить. Однажды я принял такой подход к PoC, написав лишь минимальное количество юнит-тестов для реализованных функций. В какой-то момент я получил сигнал, что компания хочет отправить его в продакшн, и внезапно мне понадобилось значительно больше времени, чем ожидалось. Добавление тестов показало, что мой код работал не так хорошо, как я думал, что привело меня к полному редизайну.
Это нормально, что мы не вкладываем столько же усилий в тестирование PoC; однако мы все равно должны поддерживать достойный уровень охвата тестированием, чтобы гарантировать правильность нашего кода и избежать неприятных сюрпризов, если проект продвинется вперед.
Обсуждение закрыто.