Экстремальное программирование. Разработка через тестирование

Храбрость
TDD 
– 
это 
спо соб 
управления 
страхом 
в 
процессе
программирования. Я не имею в вид у страх пад ения со стула или страх
перед начальником. Я имею в вид у страх перед зад ачей, «настолько
сложной, что я пока понятия не имею, как ее решить». Боль – это когд а
природ а говорит нам: «Стоп!», а страх – это когд а природ а говорит нам:
«Буд ь о сторожен!» Осторожно сть – это совсем не плохо, од нако
помимо пользы страх оказывает на нас некоторое негативное влияние:
• страх заставляет нас заблаговременно и тщательно обд умывать, к
чему может привести то или иное д ействие;
• страх заставляет нас меньше общаться;
• страх заставляет нас пугаться отзывов о нашей работе;
• страх д елает нас разд ражительными.
Ничего из этого нельзя назвать полезным д ля процесса
программирования, о собенно если вы работаете над сложной зад ачей.
Итак, перед нами встает вопро с, как выйти из сложной ситуации и
• не пытаться пред сказать буд ущее, а немед ленно приступить к
практическому изучению проблемы;
• не отгораживаться от о стального мира, а повысить уровень
коммуникации;
• не избегать откликов, а, напротив, установить над ежную
обратную связь и с ее помощью тщательно контролировать результаты
своих д ействий;
• (с разд ражением вы д олжны справиться само стоятельно).
Сравним программирование с под ъемом вед ра из колод ца. Вед ро
наполнено вод ой, вы вращаете рычаг, наматывая цепь на ворот и
под нимая вед ро наверх. Если вед ро небольшое, вполне под ойд ет
обычный, свобод но вращающийся ворот. Но если вед ро большое и
тяжелое, вы устанете прежд е, чем под нимете его. Чтобы получить
возможно сть отд ыхать межд у поворотами рычага, необход им храповой
механизм, позволяющий фиксировать рычаг. Чем тяжелее вед ро, тем
чаще д олжны след овать зубья на шестеренке храповика.
Тесты в TDD – это зубья на шестеренке храповика. Заставив тест
работать, мы знаем, что теперь тест работает, отныне и навеки. Мы
стали на шаг ближе к завершению работы, чем были д о того, как тест
заработал. По сле этого мы заставляем работать второй тест, затем
третий, четвертый и т. д . Чем сложнее проблема, стоящая перед

---

программистом, тем меньше функциональных возможно стей д олжен
охватывать кажд ый тест.
Читатели книги 
Extreme Programming Explaine
[1]
, д олжно быть,
обратили внимание на разницу в тоне межд у экстремальным
программированием (Extreme Programming, XP) и разработкой через
тестирование (Test-Driven Development, TDD). В отличие от XP метод ика
TDD не является абсолютной. XP говорит: «чтобы д вигаться д альше, вы
обязаны о своить это и это». TDD – менее конкретная метод ика. TDD
пред полагает наличие интервала межд у принятием решения и
получением результатов, и пред лагает инструменты управления
прод олжительно стью этого интервала. «Что, если в течение нед ели я
буд у проектировать алгоритм на бумаге, а затем напишу код ,
использовав под ход “сначала тесты”? Буд ет ли это соответствовать
TDD?» Конечно, буд ет. Вы знаете величину интервала межд у принятием
решения и оценкой результатов и о сознанно контролируете этот
интервал.
Большинство люд ей, о своивших TDD, утвержд ают, что их практика
программирования изменилась к лучшему. 
Инфицированные тестами
(test infected) – такое опред еление прид умал Эрих Гамма (Erich Gamma),
чтобы описать д анное изменение. Освоив TDD, вы обнаруживаете, что
пишете значительно больше тестов, чем раньше, и д вигаетесь вперед
малюсенькими 
шагами, 
которые 
раньше 
показались 
бы 
вам
бессмысленными. С д ругой стороны, некоторые программисты,
познакомившись с TDD, решают вернуться к использованию прежних
практик, зарезервировав TDD д ля о собых случаев, когд а обычное
программирование не привод ит к желаемому прогрессу.
Опред еленно, существуют зад ачи, которые невозможно (по крайней
мере, на текущий момент) решить только при помощи тестов. В
частно сти, TDD не позволяет механически прод емонстрировать
ад екватно сть разработанного код а с точки зрения безопасно сти д анных
и над ежно сти выполнения параллельных операций. Безусловно,
безопасно сть о снована на код е, в котором не д олжно быть д ефектов,
од нако она о снована также на участии человека в процед урах защиты
д анных. Тонкие проблемы параллельного выполнения операций
невозможно с уверенно стью во спроизвести, про сто запустив некоторый
код .
Прочитав эту книгу, вы сможете:
• начать применять TDD;
• писать автоматические тесты;

---

• выполнять рефакторинг, воплощая решения по од ному за раз.
Книга разд елена на три части.