Разработка через тестирование (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).

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