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

Предисловие 
Чистый код, который работает
(clean code that works), – в этой
короткой, но сод ержательной фразе, прид уманной Роном Джеффризом
(Ron Jeffries), кроется весь смысл метод ики разработки через
тестирование (Test-Driven Development, TDD). Чистый код , который
работает, – это цель, к которой стоит стремиться потому, что
• это пред сказуемый спо соб разработки программ. Вы знаете, когд а
работу можно считать законченной и не беспокоиться о д линной черед е
ошибок;
• д ает шанс усвоить уроки, которые препод но сит код . Если вы
во спользуетесь первой же ид еей, которая пришла в голову, у вас не
буд ет шанса реализовать вторую, лучшую ид ею;
• улучшает жизнь пользователей ваших программ;
• позволяет вашим коллегам рассчитывать на вас, а вам –
рассчитывать на них;
• писать такой код приятнее.
Но как получить чистый код , который работает? Многие силы
мешают нам получить чистый код , а иногд а не уд ается д аже получить
код , который про сто работает. Чтобы избавиться от множества проблем,
мы буд ем разрабатывать код , опираясь на автоматизированное
тестирование. Такой стиль программирования называется разработкой
через тестирование. Согласно этой метод ике
• новый код пишется только по сле того, как буд ет написан
автоматический тест, завершающийся неуд ачей;
• любое д ублирование устраняется.
Два про стых правила, не правд а ли? Од нако они генерируют
сложное инд ивид уальное и групповое повед ение со множеством
технических по след ствий:
• в процессе проектирования мы по стоянно запускаем код и
получаем пред ставление о его работе, это помогает принимать
правильные решения;
• мы сами пишем тесты, так как не можем жд ать, что кто-то д ругой
напишет тесты д ля нас;
• наша сред а разработки д олжна быстро реагировать на небольшие
мод ификации код а;
• д изайн программы д олжен базироваться на использовании

---

множества 
автономных, 
слабо 
связанных 
компонентов, 
чтобы
упро стить тестирование код а.
Два упомянутых правила TDD опред еляют поряд ок этапов
программирования.
1. Красный – напишите небольшой тест, который не работает, а
возможно, д аже не компилируется.
2. Зеленый – заставьте тест работать как можно быстрее, при этом
не д умайте о правильно сти д изайна и чистоте код а. Напишите ровно
столько код а, чтобы тест сработал.
3. Рефакторинг – устраните из написанного код а любое
д ублирование.
Красный – зеленый – рефакторинг – это мантра TDD.
Если д опустить, что такой стиль программирования возможен,
можно пред положить, что благод аря его использованию код буд ет
сод ержать существенно меньше д ефектов, кроме того, цель работы
буд ет ясна всем, кто принимает в ней участие. Если так, тогд а
разработка только код а, необход имого д ля прохожд ения тестов,
привод ит также к социальным по след ствиям:
• при д о статочно низкой плотно сти д ефектов команд а контроля
качества (Quality Assurance, QA) сможет перейти от реагирования на
ошибки к их пред упрежд ению;
• с уменьшением количества неприятных сюрпризов менед жеры
проекта смогут точнее оценить труд озатраты и вовлечь заказчиков в
процесс разработки;
• если темы технических д искуссий буд ут четко опред елены,
программисты смогут взаимод ействовать д руг с д ругом по стоянно, а не
раз в д ень или раз в нед елю;
• и снова при д о статочно низкой плотно сти д ефектов мы сможем
кажд ый 
д ень 
получать 
интегрированный 
рабочий 
прод укт 
с
д обавленной в него новой функционально стью, благод аря чему мы
сможем вступить с нашими заказчиками в д еловые отношения
совершенно нового типа.
Итак, ид ея про ста, но в чем наш интерес? Почему программист
д олжен 
взять 
на 
себя 
д ополнительную 
обязанно сть 
писать
автоматизированные тесты? Зачем программисту д вигаться вперед
малюсенькими шажками, когд а его мозг в со стоянии прод умать горазд о
более сложную структуру д изайна? Храбро сть.

---