Разработка через тестирование.
Дисциплина разработки, при которой вы пишете падающий тест до кода, который заставит его пройти, а затем рефакторите — позволяя тестам управлять дизайном в коротких, плотных циклах.
##Intent
Управляйте дизайном и проверяйте корректность кода, написав падающий тест для каждого небольшого фрагмента поведения до написания кода, который ему удовлетворяет, а затем улучшая дизайн, пока тесты держат вас в безопасности.
##Problem
Код, написанный без тестов, рискованно менять: нет быстрого способа узнать, не сломала ли правка что-нибудь. Тесты, написанные постфактум, как правило, поверхностны, подогнаны под код, который, возможно, уже трудно тестировать, и редко влияют на дизайн.
Без вынуждающего фактора дизайн также склонен разрастаться запутанным и трудным для прогона в изоляции.
##Solution
Работайте в коротком цикле Красный — Зелёный — Рефакторинг (Red-Green-Refactor):
- Красный — напишите небольшой тест для следующего фрагмента поведения и посмотрите, как он падает.
- Зелёный — напишите простейший код, который заставит тест пройти, пусть даже уродливый.
- Рефакторинг — приведите код (и тесты) в порядок теперь, когда они зелёные, а набор защищает от регрессий.
Повторяйте в циклах длиной в минуты. Поскольку тесты идут первыми, код тестируем по построению, а набор документирует предполагаемое поведение.
##Structure
- Цикл — Красный → Зелёный → Рефакторинг, непрерывно повторяемый.
- Список тестов — текущий перечень поведений, которые ещё предстоит покрыть.
- Arrange–Act–Assert — форма сфокусированного модульного теста.
- Тестируемый модуль — небольшой срез поведения, который фиксирует каждый тест.
##Applicability
- Используйте её для кода с реальной логикой и ветвлением и для долгоживущего кода, который будет часто меняться.
- Особенно ценна там, где важны быстрая обратная связь и защита от регрессий.
- Менее подходит для одноразовых спайков или исследовательской работы над UI, где дизайн ещё не устоялся.
##How to Implement
- Выберите следующее небольшое поведение из вашего списка тестов.
- Напишите тест, утверждающий его, и запустите набор, чтобы увидеть падение (красный).
- Напишите минимальный код, необходимый для прохождения; запустите набор (зелёный).
- Рефакторите боевой и тестовый код, удерживая набор зелёным.
- Повторяйте, добавляя поведения в список по мере их обнаружения.
##Pros & Cons
- Высокое покрытие тестами как побочный продукт, а не как запоздалая мысль.
- Быстрая обратная связь ловит регрессии за секунды.
- Поощряет слабосвязанный, тестируемый дизайн.
- Набор выступает живой, исполняемой документацией.
- Более медленный начальный темп и реальная кривая обучения.
- Может чрезмерно акцентировать изолированные модули, упуская пробелы в интеграции.
- Тесты — тоже код: их нужно сопровождать и рефакторить.
- Не заменяет исследовательское, интеграционное или сквозное тестирование.
