Уменьшение количества дефектов. Имею ли я право утверждать, что подобное возможно? Есть ли у меня научное доказательство?
Нет. На текущий момент не проводилось никаких исследований, подтверждающих преимущества TDD по сравнению с альтернативными подходами в смысле качества, эффективности или удовольствия. Однако эпизодические подтверждения преимуществ TDD многочисленны, а вторичные эффекты очевидны. При использовании TDD у программистов действительно снижается стресс, в командах действительно повышается доверие, а заказчики действительно начинают смотреть на каждую новую версию продукта с энтузиазмом. Лично мне не приходилось сталкиваться с обратными эффектами. Однако ваши наблюдения могут оказаться иными, вы должны попробовать для того, чтобы оценить TDD самостоятельно.
Еще одним преимуществом методики TDD, объясняющим ее положительные эффекты, является сокращение времени, которое проходит между принятием проектного решения и проверкой результата его реализации. В рамках TDD это достаточно короткий промежуток времени – несколько секунд или минут. Вы принимаете решение, реализуете его в коде, запускаете тесты и анализируете полученный результат. В начале у вас возникает мысль – возможно, API должен выглядеть так, или, возможно, метафора должна быть такой, – затем вы создаете самый первый пример – тест, который воплощает вашу мысль в реальность. Вместо того чтобы сначала проектировать, а затем в течение нескольких недель или месяцев ожидать, окажется ваше решение правильным или нет, вы получаете результат уже через несколько секунд или минут.
Причудливый ответ на вопрос, «Почему TDD работает?», основан на бредовом видении из области комплексных систем. Неподражаемый Флип пишет:
Следует использовать программистские практики, которые «притягивают» корректный код как предельную функцию, но не как абсолютную величину. Если вы пишете тесты для каждой присутствующей в системе функциональности, если вы добавляете в систему новые функции по одной, и только после того, как выполнятся все тесты, вы создадите то, что математики обозначают термином «точка притяжения (аттрактор)». Точка притяжения – это точка в пространстве состояний, к которой сходятся все потоки. Со временем код с большей вероятностью изменяется в лучшую сторону, а не в худшую; точка притяжения приближается к корректности, как предельная функция.
Это «корректность», которая устраивает всех программистов (за исключением, конечно же, тех, кто работает над медицинским или аэрокосмическим программным обеспечением). Я считаю, что важно быть знакомым с концепцией точки притяжения – ее не следует отвергать, ею не следует пренебрегать.
Что означает название?Название методики: Test-Driven Development – разработка через тестирование. Буквально можно перевести как «разработка, ведомая тестами» или «разработка исходя из тестов».
Development (разработка) – старый поэтапный подход к разработке программного обеспечения обладает рядом недостатков, так как оценить результат проектного решения очень сложно, если решение и оценка результатов удалены друг от друга по времени. В названии TDD термин «разработка» означает сложную комбинацию анализа, логического проектирования, физического проектирования, реализации, тестирования, пересмотра, интеграции и выпуска.
Driven (исходя из, через) – в свое время я называл TDD термином test-first programming (программирование «вначале тесты»). Однако антонимом слова fist (вначале) является слово last (в конце). Огромное количество людей осуществляют тестирование уже после того, как они запрограммировали функциональный код. Этот подход считается вполне приемлемым. Существует любопытное правило именования, согласно которому противоположность придуманного вами имени должна быть, по крайней мере отчасти, неприятной или неудовлетворительной. (Термин «структурное программирование» звучит привлекательно, так как никто не хочет писать бесструктурный, то есть неорганизованный код.) Если в ходе разработки я исхожу не из тестов, то из чего? Из предположений? Домыслов? Спецификаций? (Обратите внимание, что слово «спецификация» немножко похоже на слово «спекуляция».)
Test (тест) – автоматическая процедура, позволяющая убедиться в работоспособности кода. Нажмите кнопку, и он будет выполнен. Ирония TDD состоит в том, что это вовсе не методика тестирования. Это методика анализа, методика проектирования, фактически методика структурирования всей деятельности, связанной с разработкой программного кода.
Как методика TDD связана с практиками экстремального программирования?Некоторые из рецензетов данной книги, были обеспокоены тем, что книга целиком и полностью посвящена TDD, в результате читатели могут подумать, что остальными практиками XP (eXtreme Programming – экстремальное программирование) можно пренебречь. Например, если вы работаете в стиле TDD, должны ли вы при этом работать в паре? Далее я привожу перечень соображений относительно того, как остальные практики XP улучшают эффективность TDD и, наоборот, как TDD повышает эффективность использования других практик XP.
Программирование в паре. Тесты, разрабатываемые в рамках TDD, являются превосходным инструментом общения, когда вы программируете в паре. Зачастую, работая в паре, партнеры не могут договориться – какую именно проблему они решают, несмотря на то что работают с одним и тем же кодом. Это звучит бредово, однако подобное происходит постоянно, в особенности когда вы только осваиваете работу в паре. Именно этой проблемы удается избежать благодаря TDD. Существует и обратное влияние: когда вы работаете в паре, у вас есть помощник, который может взять на себя нагрузку в случае, если вы устали. Ритм TDD может исчерпать ваши силы, и тогда вы будете вынуждены программировать, несмотря на усталость. Однако если вы работаете в паре, ваш партнер готов взять у вас клавиатуру и тем самым дать вам возможность немного расслабиться.
Работа на свежую голову. XP рекомендует работать, когда вы полны сил, и останавливать работу, когда вы устали. Если вы не можете заставить следующий тест сработать или заставить работать те два теста одновременно, значит, настало время прерваться. Однажды мы с дядей Бобом Мартином (Bob Martin[31]) работали над алгоритмом разбиения линии, и нам никак не удавалось заставить его работать. Несколько минут мы безуспешно бились над кодом, однако нам стало очевидно, что прогресса нет, поэтому мы просто остановили работу.
Частая интеграция. Тесты – это великолепный ресурс, который позволяет выполнять интеграцию значительно чаще. Вы добились успешного выполнения очередного теста, избавились от дублирования, значит, вы можете интегрировать код. Этот цикл может повторяться каждые 15–30 минут. Возможность частой интеграции позволяет более многочисленным командам разработчиков иметь дело с одной и той же
