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

Можно ли использовать TDD для разработки крупномасштабных
систем?
Позволяет ли метод ика TDD разрабатывать крупномасштабные
программные проекты? Какие новые типы тестов вам потребуется
написать? Какие новые шаблоны рефакторинга могут потребоваться?
Самой крупной программной системой, целиком и полно стью
разработанной в стиле TDD, в созд ании которой я принимал участие,
является система LifeWare (www.lifeware.ch). Работа над системой велась
в течение 4 лет. Объем работ оценивается в 40 человеко-лет. На текущий
момент система включает в себя 250 000 строк функционального и 250

---

000 строк тестирующего код а (на языке Smalltalk). Набор тестов
системы включает в себя 4000 тестов, д ля выполнения которых
требуется 20 минут. Полный набор тестов запускается несколько раз
кажд ый 
д ень. 
Реализованный 
в 
системе 
огромный 
объем
функционально сти, похоже, никак не снижает эффективно сти TDD.
Избавляясь от д ублирования, вы стараетесь созд ать большое количество
маленьких объектов, которые можно тестировать изолированно д руг от
д руга вне зависимо сти от размера приложения.
Можно ли осуществлять разработку через тестирование на уровне
приложения?
Если мы буд ем выполнять разработку, используя только внутренние
программистские тесты (их называют тестами мод улей – 
unit tests
, –
хотя они не вполне соответствуют этому опред елению), мы рискуем
столкнуться с проблемой: полученная в результате этого система может
оказаться не совсем тем или, что хуже, совсем не тем, что хочет
получить пользователь. Программист буд ет работать над программой,
которая, 
по его мнению
, д олжна быть полезна, од нако у пользователя
может оказаться совершенно д ругое мнение. Чтобы решить проблему,
можно разработать набор тестов на уровне приложения. Разработкой
этих тестов д олжны заниматься сами пользователи (при под д ержке
программистов). Написанные пользователями тесты д олжны точно
опред елять, что именно д олжна д елать разрабатываемая система. Такой
стиль можно назвать разработкой через тестирование на уровне
приложения (ATDD, Application Test-Driven Development).
Встает техническая проблема: как написать и запустить тест д ля
функционально сти, которая еще не существует? Мне кажется, что всегд а
можно найти спо соб решения этой проблемы. Например, можно
разработать интерпретатор, который буд ет вежливо сигнализировать о
том, что обнаружен тест, выполнить который на д анный момент
невозможно 
по 
причине 
отсутствия 
в 
системе 
необход имых
возможно стей.
Существует также социальная проблема. У пользователей (на самом
д еле я имею в вид у команд у, в со став которой вход ят пользователи)
появляется новая обязанно сть: разработка тестов. Процед ура разработки
тестов уровня приложения требует д обавления д ополнительного этапа в
цикл работы над прод уктом, – а именно, разработка пользовательских

---

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