Проектирование нового компонента начинается с автотестов для ещё не реализованного поведения. Какой основной риск снижает такой подход «сначала тесты»?
Подход «сначала тесты», обычно реализуемый через цикл красный — зелёный — рефакторинг, прежде всего снижает риск поздно обнаружить, что реализация не соответствует ожидаемому поведению. Ошибка выявляется на малом объёме изменений, когда её дешевле понять и исправить.
Подход появился как ответ на проблему поздней обратной связи: при разработке «сначала код» проверка часто откладывается до интеграции или ручного тестирования. К этому моменту сложнее определить причину сбоя, а требования могут быть интерпретированы неверно.
Автоматизируемый тест делает ожидаемое поведение явным и проверяемым ещё до появления реализации. Это не отменяет другие виды тестирования, но переносит часть обратной связи ближе к моменту проектирования и написания кода.
Если сначала реализовать компонент, а тесты добавить позже, тесты могут начать описывать уже принятое решение вместо требуемого поведения. В результате команда получает покрытие, которое подтверждает внутреннюю реализацию, но не обязательно обнаруживает ошибочную бизнес-логику.
Поздняя проверка также повышает стоимость исправления: к ошибочному решению могут успеть привязаться другие компоненты, тестовые данные и интерфейсы. Неверно выбранный подход «сначала тесты» тоже опасен: тест может формализовать неправильно понятое требование или оказаться слишком крупным и хрупким.
В цикле красный — зелёный — рефакторинг сначала формулируют один небольшой проверяемый пример поведения. Тест должен завершиться неуспешно, потому что нужного поведения ещё нет. Затем пишут минимальную реализацию, достаточную для прохождения теста, и после этого улучшают структуру кода, сохраняя зелёный результат.
Механизм снижения риска состоит в коротком цикле обратной связи. Каждый небольшой шаг проверяет конкретное предположение: какой вход подаётся, какой результат считается правильным и какое наблюдаемое поведение является обязательным.
Тест должен проверять внешний контракт компонента, а не его частные детали. Тогда рефакторинг реализации не вызывает массовых изменений тестов и не маскирует проверку поведения проверкой структуры кода.
Важно отличать TDD от простого написания тестов перед кодом. Для TDD характерен итеративный цикл с маленькими примерами и рефакторингом; большой набор тестов, написанный заранее на основе неустойчивых требований, может лишь закрепить ошибочное понимание задачи.
Подход имеет ограничения. Он не гарантирует полноту требований, плохо выявляет удобство пользовательского интерфейса и не заменяет интеграционные, исследовательские, нагрузочные и сквозные проверки. Кроме того, слишком тесная связь тестов с деталями реализации способна сохранить формальную зелёность при слабой проверке результата.
Команда разрабатывает расчёт скидки для заказа. Рассматривались два варианта: сначала создать полную реализацию с большим количеством ветвлений, а затем покрыть её тестами, либо начать с небольших примеров для обычной покупки, граничной суммы и несовместимых скидок.
Первый вариант может быстрее дать начальный код, но затрудняет локализацию ошибки и создаёт риск незаметно выбрать неверные правила. Второй вариант требует дисциплины и уточнения поведения заранее, зато каждое правило получает явную проверку до усложнения реализации.
Выбран итеративный подход «сначала тесты»: команда добавляет по одному правилу, получает красный результат, реализует его минимально и затем рефакторит общий расчёт. Это позволяет раньше обнаружить противоречие в требованиях и не привязывать проверку к внутренней структуре вычислений.
1. Достаточно ли написать тест до реализации, чтобы получить преимущества TDD?
Нет. Если тесты создаются большими пакетами, проверяют детали реализации или не проходят через короткий цикл «красный — зелёный — рефакторинг», преимущества TDD снижаются. Существенны малый размер шага, наблюдаемое поведение и регулярное улучшение дизайна.
2. Как поступать, если требование ещё не определено однозначно?
Не следует механически закреплять предположение тестом. Сначала нужно уточнить примеры поведения с представителями продукта или заказчиком; тест может помочь обнаружить противоречие, но не способен самостоятельно определить правильное бизнес-правило. До стабилизации требования допустимы более узкие проверки или исследовательские тесты, которые не становятся окончательным контрактом.
3. Может ли высокий процент покрытия доказать, что подход «сначала тесты» сработал?
Нет. Покрытие показывает, какие участки кода были выполнены, но не показывает, насколько сильны проверки и корректны ли ожидаемые результаты. Качество нужно оценивать также по смыслу утверждений, способности тестов обнаруживать изменения поведения, стабильности, уровню проверяемого контракта и результатам интеграционного или исследовательского тестирования.