Test Driven Development

      TDD или Разработка через тестирование  это одна из методологий XP(Экстремального программирования), которая позволяет разрабатывать дизайн проекта с помощью модульных тестов. Эти процессы ведут  к существенному увеличению качества и скорости разработки ПО. Данный пост ориентирован прежде всего на разработчиков, умеющих и знающих как правильно писать модульные тесты. 

   Мантра

Жизненный цикл в TDD

1. Пишется модульный тест, который не выполняется (или возможно даже не компилируется),  с кислым видом смотрим на красную полоску. Тесты  по сути являются частями технического требования, которое нужно реализовать.
2. Прилагаются минимальные действия по доработке дизайна и реализации, чтобы тест прошел, теперь можно, наслаждаясь зеленой полоской, перейти  к следующими этапу.
3. Рафакторинг кода. Рафкторинг это естественный и, в рамках итеративного проектирования, непрерывный процесс, который позволяет повысить качество кода. Тесты, написанные ранее, фиксируют функционал и поведение, инкапсулированное  в классе, поэтому можно без опасений за изменение поведения класса проводить рефакторинг.
4. Повторить первые три пункта для нового технического требования.

Преимущества

•        Разработка через тестирование предлагает больше, чем просто проверку корректности, она также влияет на дизайн программы. Изначально сфокусировавшись на тестах, проще представить, какая функциональность необходима пользователю. Таким образом, разработчик продумывает детали интерфейса до реализации.
•    Разработка   через  тестирование  способствует более модульному, гибкому и расширяемому коду. Это связано с тем, что при этой методологии разработчику необходимо думать о программе, как о множестве небольших модулей, которые написаны и протестированы независимо и лишь потом соединены вместе. Это приводит к меньшим, более специализированным классам, уменьшению связанности и более чистым интерфейсам. Использование mock-объектов также вносит вклад в модуляризацию кода, поскольку требует наличия простого механизма для переключения между mock- и обычными классами.
•   Поскольку пишется лишь тот код, что необходим для прохождения теста, автоматизированные тесты покрывают все пути исполнения. Например, перед добавлением нового условного оператора, разработчик должен написать тест, мотивирующий добавление этого условного оператора. В результате получившиеся в результате разработки через тестирование тесты достаточно полны: они обнаруживают любые непреднамеренные изменения поведения кода.
•       Отличная интеграция с  другими практиками XP, такими как непрерывная интеграция и парное программирование.   

Недостатки

•    Мотивация руководства очень важна - понимание , что модульные тесты повысят качество всей разрабатываемой системы, иначе фокусировки не будет, и тесты будут расцениваться как аппендикс проекта. 
•    В некоторых случаях невозможно производить модульные тестирование проекта( в случаях работы с БД, пользовательскими интерфейсами),в  этом случае разработка через тестирование сильно затруднена
•     Обязательное  написание  модульных  тестов  создает  дополнительные   накладные расходы на их поддержу, однако эта проблема минимизируется применением паттернов тестирования
•    Модульные тесты, создаваемые при разработке через тестирование, обычно пишутся тем же, кто пишет тестируемый код. Если разработчик неправильно истолкует требования к приложению, и тест и тестируемый модуль будут содержать ошибку.

Я участвовал в   нескольких проектах  с использованием TDD  в качестве философии разработки, и они показали отличные результаты. Ярким примером является p2p трекер , в этом проекте была детально проработана спецификации требований, что позволило достаточно прозрачно проводить циклы red-green-refactor.