Red-green-refactor — это цикл проектирования, а не ритуал тестирования

Прию просят добавить фичу «отмена заказа». Она пишет тест первым и сразу упирается в стену: чтобы проверить результат, ей надо собрать OrderService, которому нужны соединение с БД, платёжный шлюз, почтовый клиент и сервис фича-флагов — четыре коллаборатора, только чтобы протестировать одно булево правило. Тест невозможно написать чисто. Её коллега заметил бы это лишь после того, как cancel() уже вшит в контроллер, две джобы и админ-скрипт. Ненаписуемый тест — это и есть ревью дизайна: OrderService делает слишком много, и TDD сказал об этом до единой строки продакшен-кода.

Первый шаг — это давление на дизайн, а не покрытие

Цикл намеренно крошечный: написать наименьший падающий тест (red), написать наименьший код, делающий его зелёным (green), затем улучшить код, не меняя поведения (refactor). Ценность, которую большинство упускает, целиком живёт в шаге red. Написание теста до реализации заставляет вас вызывать собственный код снаружи до того, как он существует — вы выбираете имя функции, её аргументы, форму возврата и режим отказа, пока вы всё ещё потребитель, а не автор. Код, который неудобно вызывать, неудобно тестировать первым, поэтому плохой интерфейс всплывает за секунды, а не после того, как его вшили в пятнадцать мест вызова, которые теперь все надо менять.

Это переосмысляет всю практику. Люди спорят о TDD так, будто вопрос в том, «находит ли написание тестов первыми больше багов?». Это мимо. Механизм — это задержка обратной связи о дизайне: труднособираемый объект, метод, которому нужно шесть моков, функция, чей возврат нельзя проверить, не залезая во внутренности — это запахи дизайна, и тест-сначала вскрывает их в самый дешёвый момент, до того как дизайн прорастёт в кодовую базу. Сравнительный кейс-стади на arXiv показал, что эффект на дизайн был устойчивым сигналом во всех командах; эффект на число багов был шумнее.

Пропуск refactor — вот как цикл гниёт

Самый частый провал — остановиться на green. Под дедлайном ритуал схлопывается до «тест прошёл, выкатываем», и третий шаг — refactor — тихо исчезает. А это шаг, где убирается дублирование и чинятся запутанные имена пока тесты всё ещё стерегут поведение. Пропускайте его квартал — и у вас зелёный CI поверх кодовой базы, которую никто не хочет трогать. Зелёный — не здоровье. Прохождение тестов говорит, что поведение сохранено; оно ничего не говорит о том, осталась ли форма кода такой, которую человек может менять.

Здесь есть реальная цена, и притворяться иначе нечестно. Индустриальные данные оценивают тест-сначала примерно в 15–22% больше времени на входе, чем тест-потом для той же фичи. Размен — это смещённая вперёд обратная связь по дизайну и регрессионная сеть против последующих переделок — поэтому отдача TDD выше всего на долгоживущем, часто меняемом коде и слабее всего на одноразовых скриптах. Полностью разрешим это противоречие в уроке 04; пока суть в том, что шаг refactor — это где приземляется большая часть долгосрочной выгоды, и это первое, что команды срезают.

Привязывайтесь к поведению, или набор станет обузой

Тихий убийца — это что вы проверяете. Тест, привязанный к поведению — «возврат за полностью отгруженный заказ отклоняется» — переживает любой рефакторинг, сохраняющий результат, поэтому он защищает вас, пока вы улучшаете код. Тест, привязанный к реализации — «RefundService вызывает inventoryClient.check() ровно раз, затем ledger.post()» — ломается в тот же миг, когда вы реорганизуете внутренности, даже если для клиента ничего не изменилось. Команда усваивает, что red обычно шум, и начинает его игнорировать. Именно так набор сползает из актива в обузу: это анти-паттерн хрупкого теста, описанный в xUnit Test Patterns.

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