61 / 94
Scrum и XP: заметки с передовой
61
Разработка через тестирование (TDD)
Н к нец-то! Ра работка через тестирование для меня важнее, чем Scrum и XP вместе взятые. Можете
отнять у меня дом, телевизор, собаку, но только попробуйте запретить использование TDD! Если вам не
нравится TDD, тогда просто не подпускайте меня близко, иначе я всё равно привнесу его в проект втихую :)
Курс TDD за 10 секунд:
Разработка через тестирование означает, что вы сначала должны написать
автоматизированный тест (который не проходит – прим. переводчика). После этого надо
написать ровно столько кода, чтобы тест прошёл. Затем необходимо провести
рефакторинг, в основном, чтобы улучшить читабельность кода и устранить
дублирование. При необходимости повторить
.
Несколько фактов о TDD:
•
Разработка через тестирование – это
непросто
. На деле оказывается, что демонстрировать TDD
программисту практически бесполезно – часто единственный действенный способ
заразить
его
TDD заключается в следующем. Программиста надо обязать работать в паре с кем-то, кто в TDD
хорош. Но как только программист
вник
в TDD, то он уже заражен серьезно и о разработке другим
способом даже слышать не хочет.
•
TDD оказывает глубокое положительное влияние на дизайн системы.
•
Чтобы TDD стало приносить пользу в новом проекте, необходимо приложить немало усилий.
Особенно много тратится на интеграционные тесты методом "черного ящика". Но эти усилия
окупаются
очень быстро
.
•
Потрать достаточно времени, но сделай так, чтобы писать тесты
было просто
. То есть надо
получить необходимый инструментарий, обучить персонал, обеспечить создание правильных
вспомогательных и базовых классов и т.д.
Мы используем следующие инструменты для разработки через тестирование:
•
jUnit / httpUnit / jWebUnit. Мы присматриваемся к TestNG и Selenium.
•
HSQLDB в качестве встроенной БД в памяти (in-memory) для тестовых целей.
•
Jetty в качестве встроенного web-контейнера в памяти (in-memory) для тестовых целей.
•
Cobertura для определения степени покрытия кода тестами.
•
Spring framework для написания различных типов тестовых фикстур (в т.ч. с использованием моков
(mock-object) и без, с внешней БД и БД в памяти (in-memory) и т.д.)
В наших наиболее сложных продуктах (с точки зрения TDD) у нас реализованы автоматизированные
приёмочные тесты методом "черного ящика". Эти тесты загружают всю систему в память, включая базы
данных и web-сервера, и взаимодействуют с системой только через внешние интерфейсы (например, через
HTTP).
Такой подход позволяет получить быстрые циклы "разработка-сборка-тест". Он так же выступает в
качестве страховки, придавая разработчикам уверенность в успешности частого рефакторинга кода. В свою
очередь, это обеспечивает простоту и элегантность дизайна даже в случае разрастания системы.
TDD и новый код
Мы используем TDD для всех новых проектов, даже если это означает, что фаза развёртывания рабочего
окружения проекта потребует больше времени (потому что нужно больше усилий на настройку и поддержку
тестовых утилит). Нетрудно понять, что выгода перевесит любой предлог
не внедрять
TDD.
TDD и существующий код
Я уже говорил, что TDD – это непросто, но что
действительно сложно
, так это пытаться применять TDD
для кода, который изначально не был спроектирован для применения этого подхода! Почему? Эту тему