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

Следует использовать программистские практики, которые «притягивают» корректный код как предельную функцию, но не как абсолютную величину. Если вы пишете тесты для каждой присутствующей в системе функциональности, если вы добавляете в систему новые функции по одной, и только после того, как выполнятся все тесты, вы создадите то, что математики обозначают термином «точка притяжения (аттрактор)». Точка притяжения – это точка в пространстве состояний, к которой сходятся все потоки. Со временем код с большей вероятностью изменяется в лучшую сторону, а не в худшую; точка притяжения приближается к корректности, как предельная функция.

Это «корректность», которая устраивает всех программистов (за исключением, конечно же, тех, кто работает над медицинским или аэрокосмическим программным обеспечением). Я считаю, что важно быть знакомым с концепцией точки притяжения – ее не следует отвергать, ею не следует пренебрегать.

Что означает название?

Название методики: Test-Driven Development – разработка через тестирование. Буквально можно перевести как «разработка, ведомая тестами» или «разработка исходя из тестов».

 Development (разработка) – старый поэтапный подход к разработке программного обеспечения обладает рядом недостатков, так как оценить результат проектного решения очень сложно, если решение и оценка результатов удалены друг от друга по времени. В названии TDD термин «разработка» означает сложную комбинацию анализа, логического проектирования, физического проектирования, реализации, тестирования, пересмотра, интеграции и выпуска.

 Driven (исходя из, через) – в свое время я называл TDD термином test-first programming (программирование «вначале тесты»). Однако антонимом слова fist (вначале) является слово last (в конце). Огромное количество людей осуществляют тестирование уже после того, как они запрограммировали функциональный код. Этот подход считается вполне приемлемым. Существует любопытное правило именования, согласно которому противоположность придуманного вами имени должна быть, по крайней мере отчасти, неприятной или неудовлетворительной. (Термин «структурное программирование» звучит привлекательно, так как никто не хочет писать бесструктурный, то есть неорганизованный код.) Если в ходе разработки я исхожу не из тестов, то из чего? Из предположений? Домыслов? Спецификаций? (Обратите внимание, что слово «спецификация» немножко похоже на слово «спекуляция».)

 Test (тест) – автоматическая процедура, позволяющая убедиться в работоспособности кода. Нажмите кнопку, и он будет выполнен. Ирония TDD состоит в том, что это вовсе не методика тестирования. Это методика анализа, методика проектирования, фактически методика структурирования всей деятельности, связанной с разработкой программного кода.

Как методика TDD связана с практиками экстремального программирования?

Некоторые из рецензетов данной книги, были обеспокоены тем, что книга целиком и полностью посвящена TDD, в результате читатели могут подумать, что остальными практиками XP (eXtreme Programming – экстремальное программирование) можно пренебречь. Например, если вы работаете в стиле TDD, должны ли вы при этом работать в паре? Далее я привожу перечень соображений относительно того, как остальные практики XP улучшают эффективность TDD и, наоборот, как TDD повышает эффективность использования других практик XP.