[spoiler]Andrew Binstock написал развернутый комментарий к критике TDD:
Если ваша цель -- добиться большего покрытия кода тестами, замечательно, добавляйте их куда и где угодно -- но это не будет TDD. Более того, при этом вы ошибочно применяете и основные принципы тестирования.
В TDD вы должны сперва подумать о будущем коде (логике), перед тем, как начать кодировать. Это происходит небольшими итерациями, в ходе которых проясняются сложные моменты, учитывается незаконченная функциональность разных модулей программы, строятся правильные внутренние интерфейсы. Программист мыслит не на уровне конкретных операторов, а терминами интерфейсов и их взаимодействий. В результате получается хорошо спроектированный код, качество которого вдобавок контролируется тестами.
У TDD конечно немало ограничений. Код формируется слишком короткими и слишком частыми итерациями; тесты нередко "ломаются" после рефакторинга кода; в общем случае, совмещение TDD с рефакторингом весьма сложно. Сегодня этому аспекту уделяется мало внимания, но по хорошему TDD надо учить неразрывно в обучением практикам рефакторинга.
Аджайл не был бы аджайлом, если бы сам постоянно не развивался. Упомянутые ограничения TDD попытался обойти Dan North, предложивший agile-методику behaviour-driven development (BDD). После проведения множества семинаров по TDD в разных организациях он выявил типичные непонятности: программисты часто спрашивали, а с чего им начать; что тестировать, а что нет; сколько надо тестировать за раз; как вызывать сами тесты; как понять, почему тест не сработал.
BDD расширяет TDD сильной идеей использования естественного языка при описании тестов. При этом от понятия "тест" было решено в конце концов отказаться, вместо него введено более емкое "поведение". В процессе обсуждения с заказчиком функциональности происходит предварительное проектирование системы на естественном языке -- фразы записываются в определенном формализованном виде, фактически как на DSL-языке. В результате при дальнейшей разработке сохраняется живая связь с заказчиком, упрощается документирование, в формировании требований и их тестировании трудятся все участники процесса (от пользователей до менеджеров), а программист "с ходу" понимает, что кодирует: но если раньше это понимание не слишком естественно вырабатывали тесты, то теперь оно задается подробным словесным именем функции или метода.
Вдохновившись успехами BDD, North взялся за разработку системы JBehave -- аналога JTest, из которой было исключено понятие теста -- точнее, заменено на "верифицирование поведения". JBehave создана самоверифицируемой: в нее добавлено "поведение", позволяющее исполнять саму себя.
Следующим шагом в развитии JBehave стал поиск ответов на вопросы "какая следующая самая важная вещь, которую система не делает" и "с чего начать реализацию". Раздумывая над этим с Eric Evans-ом (автором agile-бестселлера "Domain-Driven Design"), коллеги пришли к выводу, что хотят получить в конечном итоге полноценный язык для анализа процесса работы программы. Они разработали концепцию сценариев, иллюстрирующих конкретный аспект поведения системы, и шаблоны описания требований. Добавился в BDD и принцип "снаружи вовнутрь" -- он делает акцент на пользовательском интерфейсе, от которого развивается вся струтура программы.
Теперь BDD развивается именно в направлении анализа процесса под лозунгом Its All Behavior. Основной ресурс коммьюнити -- сайт behaviour-driven.org.
BDD поддерживается в немалом числе свободных фреймворков:
- JBehave
- SpecFlow
- NBehave для .NET
- NSpecify
- Cucumber
- GivWenZen
Многие из них включают инструменты для записи требований на естественном языке с возможностью последующего перевода в формализованный DSL-вид.
Схожий принцип, кстати, был реализован и в расширении TDD -- вариант Acceptance Test-driven development подразумевает автоматическую трансляцию в приемочные тесты требований, записанных в форме, принятой в BDD.
