Разработка через тестирование: что это даёт заказчику

Разработка через тестирование (TDD, test-driven development) — подход, при котором программист сначала пишет автоматический тест, описывающий нужное поведение, и только потом код, который заставляет этот тест пройти. Звучит как перевёрнутый порядок, но у подхода есть понятные последствия для бизнеса.

Цикл TDD

1. Красный: пишется тест для небольшой функции, которой ещё нет. Тест, естественно, не проходит.
2. Зелёный: пишется минимальный код, чтобы тест прошёл.
3. Рефакторинг: код приводится в порядок, при этом тест продолжает проходить.

Цикл короткий и повторяется много раз в день. В итоге каждая часть логики покрыта проверкой, которую можно запустить за секунды.

Пример на бизнес-правиле

Правило: «скидка постоянного клиента не суммируется с акционной ценой, применяется большая из двух». Разработчик сначала пишет тесты: клиент без скидки покупает акционный товар; клиент со скидкой покупает обычный товар; клиент со скидкой покупает акционный товар, где акция выгоднее; то же, где скидка выгоднее. Только потом пишет расчёт. Через год другой разработчик меняет логику скидок, и если что-то сломалось, тесты сразу это покажут.

Что получает заказчик

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

Цена подхода

На старте разработка идёт медленнее: часть времени уходит на тесты. Выигрыш проявляется на длинной дистанции — при доработках, поддержке и исправлениях. Для прототипа, который проверяет гипотезу и может быть выброшен, строгий TDD избыточен.

Где TDD особенно оправдан

• Расчёты: цены, скидки, налоги, начисления, бонусы, комиссии
• Правила статусов: жизненный цикл заказа, заявки, договора
• Интеграции: преобразование данных между форматами разных систем
• Логика доступа: кто что может видеть и менять
• Долгоживущие системы, которые будут развиваться годами

Где можно обойтись без него

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

TDD и другие виды тестов

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

Как проверить подрядчика

Спросите, какие тесты пишет команда и запускаются ли они автоматически при каждом изменении кода. Попросите показать отчёт о прогоне тестов. Уточните в договоре, что тесты являются частью передаваемого кода. Если подрядчик говорит «мы тестируем руками перед сдачей», это нормальная, но другая практика — и с ростом системы каждое изменение придётся перепроверять вручную.

Как TDD сочетается со сроками

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

Распространённые заблуждения

«Покрытие тестами 100% — значит, ошибок нет». Нет: тесты проверяют только то, что в них заложено. «TDD — это про тестировщиков». Нет: это практика программистов. «С тестами разработка всегда дольше». На первом этапе — да, на всём жизненном цикле — часто наоборот.