test-driven-development

Навык test-driven-development из репозитория obra/superpowers описывает строгий цикл разработки через тесты. Его центральное правило сформулировано однозначно: перед production-кодом должен появиться тест, который сначала не проходит. В исходнике это названо Iron Law — “NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST”. Поэтому навык применим к новой функции, исправлению бага, рефакторингу и изменению поведения. Для throwaway-прототипов и сгенерированных или конфигурационных файлов указаны исключения, но в остальных случаях навык требует не откладывать проверку на конец работы. Первый этап — RED. Нужно написать один небольшой тест для одного поведения с ясным названием и реальным кодом, а затем запустить его отдельно. Ожидается именно корректный failure, вызванный отсутствующей реализацией, а не опечаткой, неверным импортом или ошибкой настройки. Если тест сразу проходит, он не доказывает нужное изменение и его следует пересмотреть. Если тест падает из-за инфраструктурной ошибки, сначала исправляется причина такого запуска, после чего снова проверяется содержательный failure. В исходных примерах отдельно не приветствуются тесты, которые проверяют только количество вызовов mock-функции; предпочтение отдаётся наблюдаемому результату и реальному поведению. Второй этап — GREEN. Реализация должна быть минимальной и решать только поведение, зафиксированное тестом. Навык прямо предостерегает от добавления необязательных параметров, backoff-режимов, callback-ов и других возможностей “на будущее”. После написания кода тот же тест запускается снова и должен пройти без ошибок и предупреждений. Затем проверяется, что остальные тесты не сломались. Такой порядок создаёт короткий цикл обратной связи: сначала видно, что проверка способна поймать отсутствие поведения, затем появляется минимальная реализация, а после неё — подтверждение результата. Третий этап — REFACTOR. Рефакторинг разрешён только после зелёного состояния и не должен добавлять новую функциональность. Можно убрать дублирование, уточнить имена и выделить повторяющуюся логику, сохраняя все тесты зелёными. После этого цикл повторяется для следующего поведения. Для регрессии при исправлении бага навык рекомендует сначала зафиксировать воспроизводимый failing test, затем пройти тот же red-green-refactor путь. Карточка полезна как рабочая дисциплина для изменений, которые можно выразить наблюдаемым поведением. Она не утверждает, что тесты заменяют ревью, интеграционные проверки или контроль production-окружения, и не разрешает маскировать неясный дизайн большим количеством mock-объектов. Напротив, трудный тест рассматривается как сигнал упростить интерфейс или уменьшить связанность. Смысл навыка — сохранить проверяемый контракт и минимальный объём реализации, а не автоматически навязать конкретный тестовый фреймворк или архитектуру.