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

Как перейти к использованию TDD в середине работы над проектом?
У вас есть некоторый объем код а, про который можно сказать, что
он корректно работает в большей или меньшей степени. Теперь вы
хотите разрабатывать весь новый код в рамках концепции TDD. Что
д елать?
О проблеме переход а на использование TDD в серед ине работы над
проектом можно написать целую книгу (или д аже несколько книг). В
д анном небольшом разд еле я очень поверхно стно затрону несколько
связанных с этим вопро сов.
Самая большая проблема заключается в том, что код , изначально
написанный без тестов, как правило, сложен в тестировании.
Интерфейсы и взаимо связи межд у объектами нед о статочно хорошо

---

спроектированы, поэтому сложно изолировать некоторый кусок логики,
запустить его и проверить результаты.
«Над о это исправить», – скажете вы. Да, од нако любой рефакторинг
(без применения сред ств автоматизации), скорее всего, привед ет к
возникновению ошибок, и эти ошибки сложно буд ет обнаружить, так
как у вас нет тестов. Проблема яйца и курицы. Змея кусает себя за хво ст.
Замкнутый цикл саморазрушения. Что же д елать?
Прежд е всего скажу, чего д елать не над о: не над о писать тесты д ля
всего код а и выполнять рефакторинг всего код а. Для этого может
потребоваться несколько месяцев, в течение которых у вас не буд ет
времени д обавить в систему новой функционально сти. Если вы тратите
имеющиеся у вас д еньги и при этом не зарабатываете новых, д олго вы
не протянете.
Поэтому 
прежд е 
всего 
мы 
д олжны 
ограничить 
область
планируемых нами изменений. Если мы вид им часть системы, которую
можно существенно улучшить, но которая вполне может быть
о ставлена без изменений на текущий момент, мы о ставляем их без
изменений. Возможно, взглянув на код и вспомнив грехи прошлого, вы
не сможете уд ержаться от слез, од нако возьмите себя в руки, – если код
не требует немед ленного вмешательства, лучше не изменять его.
Во-вторых, мы д олжны разорвать замкнутый круг межд у тестами и
рефакторингом. Мы можем использовать в качестве обратной связи не
только тесты, но и д ругие спо собы, например чрезвычайно о сторожная
работа в паре с партнером. Мы можем использовать обратную связь
более высокого уровня, например тесты на уровне всей системы. Мы
знаем, что такие тесты не являются ад екватными, од нако они
прибавляют нам уверенно сти. Благод аря такой обратной связи мы
можем сд елать части код а, нужд ающиеся в изменении, более уд обными
д ля внесения изменений.
Через некоторое время части системы, которые по стоянно
меняются, станут выгляд еть так, как буд то их разработали с
использованием TDD. Мы мед ленно углубимся в д ремучий лес наших
старых ошибок.