test-driven-development - Разработка через проверяемый тест

Когда звать

• Когда добавляете поведение и хотите сначала увидеть тест, падающий именно из-за его отсутствия.
• Когда исправляете ошибку и нужен воспроизводящий тест, который не позволит вернуть её незаметно.

Что здесь считается разработкой через тест

Test-driven-development из Superpowers требует сначала описать ожидаемое поведение тестом и лично увидеть его отказ. Только после этого появляется рабочая реализация. Смысл первого запуска прост: если проверка сразу зелёная, ещё неизвестно, умеет ли она ловить недостающую возможность. Обычная ошибка синтаксиса тоже не подходит: отказ должен объясняться именно отсутствующим поведением, а не опечаткой в тесте.

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

Красный, зелёный, упрощение

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

После ожидаемого отказа агент добавляет самый простой код, достаточный для успеха. Развивать заодно новые настройки повторных попыток, интервалы и дополнительные режимы не требуется. Если новый тест остаётся красным, меняется реализация, а не ожидание ради зелёного результата. Если ломаются прежние проверки, это нужно устранить либо явно отразить в отчёте, а не скрывать за успехом единственного нового файла.

Отдельное уточнение проверенной версии требует запускать весь набор тестов проекта перед завершением. Граница поручения ограничивает результат работы, но не означает, что можно проверить только один узкий участок. Обнаруженные сбои, включая существовавшие раньше, должны быть названы. Лишь после зелёного результата начинается упрощение: удаление повторов, уточнение имён или выделение вспомогательной функции без добавления нового поведения.

Когда тест трудно написать

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

При исправлении ошибки исходный симптом должен стать воспроизводящим тестом. Например, в приведённой автором форме пустая почта сначала принимается ошибочно, затем проверка подтверждает отказ. Карточка относится к точному файлу из Superpowers. Мы сверили его содержание и MIT на закреплённом коммите, но не выполняли авторские примеры и не измеряли надёжность будущего кода.