Разработка через Тестирование

Что такое Разработка через тестирование?

Разработка через тестирование (test-driven development, TDD) это стиль разработки, в котором дизайн системы формируется тестами и создаётся в коротких циклах:

Написать один тест.
Написать только лишь необходимое количество кода, чтобы тест проходил.
Провести рефакторинг кода, чтобы сделать его “чистым”.

В языках программирования, таких как Java, такие циклы занимают не более пяти минут. В старых языках, с медленной компиляцией и меньшей поддержкой автоматизации рефакторинга, такой цикл занимает больше времени - около 20 минут.

Разработка через тестирование чем-то отличается для случаев крупномасштабной разработки? Нет. Это индивидуальный навык конкретного разработчика, поэтому их количество разработчиков в продуктовой группе не имеет значение.
Объем унаследованного кода, старых технологий, встраиваемого ПО не оказывает влияния на возможность применения unit-тестирования и TDD. Следовательно, большинство экспериментов в это разделе относятся и к таким случаям.

TDD-цикл должен быть …

Коротким: Время выполнение каждого теста мало. Оно должно занимать не более 5 минут на цикл.
Ритмичным: Вы отчётливо почувствуете ритм - “красный, зелёный, рефакторинг... красный, зелёный, рефакторинг...” (red-green-refactor)
Инкрементальным: Вы знаете, что при написании и прохождении новых тестов, работающий функционал наращивается инкрементально.
Сфокусированным на дизайне: Хорошо зная принципы дизайна ПО, вы откроете для себя, что TDD это не техника тестирования, а метод проектирования ПО.
Дисциплинированным: TDD это другой подход к разработке ПО. Отказ от старой привычки "code and fix" и внедрение новой потребуют дисциплины и упорства.

Почему TDD?

Тренировка TDD

Воспользуйтесь помощью тренеров по TDD

Когда наш клиент ознакомился с черновиком нашей книги, он отметил, что мы должны уделить больше внимания тренировкам. “Одна из наших ошибок в том, что мы не достаточно времени уделяли тренировкам“ - он сказал. Хотя мы с ним согласились, мы отметили, что, поскольку мы оба являлись консультантами и предоставляли такие услуги, этот совет не очень заслужил бы доверия. Мы могли бы также добавить эксперимент «Попробуй … найми нас». Таким образом, мы минимизировали это совет, связанный с наймом тренеров.

Но применительно к разработке через тестирование, мы не можем делать акцент слишком сильно: Наймите тренеров! Внедрение TDD означает “забывание” традиционных способов разработки и освоение заново, как проектировать и писать код. Мы редко встречаем людей, кто может научится этой практике самостоятельно. Большинство разработчиков нуждаются в тренере для работы в паре с ним несколько дней или недель. Тренер постоянно напоминает им писать тесты сначала и действительно вычищать свой код - включая код тестов. Он помогает им овладеть техниками TDD и рефакторинга на их реальной кодовой базе.

Разработка через тестирование может быть самой сложной гибкой практикой для внедрения, но это также одна из самых больших возможностей для улучшения качества проектирования и кода. Наймите тренеров!

Внутренние и внешние тренеры

Внешние тренеры необходимы для внедрения TDD, потому что данный навык ещё не привит внутри компании. Но по прошествии времени, воспитание внутренних тренеров снижает зависимость от их внешних коллег и снижает стоимость обучения.

Мы наблюдали несколько попыток провала в развитии внутренних тренеров. Вот некоторые их причины:

Отсутствие структурированного похода при принятии решений, кто, когда и с какими командами будет работать.
Отсутствие времени, выделенного на тренировки. Вместо этого тренеров просили заниматься обычно разработкой.
Разработчики менее охотно учились у внутренних тренеров… вы никогда не будете пророком на своей земле.
Тренерские навыки не ценились и не получали дальнейшее развитие. В результате опытные тренеры часто уходили, чтобы стать внешними консультантами.

Выбирайте как внутреннее так и внешнее обучение. Если остаётся только одно из них, это становиться рискованным. Но их комбинация может привести к хорошим результатам.

Разработка через тестирование для создания лучшей архитектуры

TDD может помочь улучшить архитектуру системы. Как?

Когда мы работаем в качестве консультантов, частый запрос состоит в помощи при работе с “негибкой архитектурой” наших клиентов. Чаще всего это сводится к проблемам в сильной связанности компонентов - распространённой проблеме в унаследованном коде, написанном без TDD, потому что разработчик-автор не пытался тестировать компонент изолированно.

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

В таком случае, TDD поддерживает слабую связанность, простоту, гибкое конфигурирование - качества хорошей архитектуры.

Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.