Background Image
Table of Contents Table of Contents
Previous Page  61 / 94 Next Page
Information
Show Menu
Previous Page 61 / 94 Next Page
Page Background

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

для кода, который изначально не был спроектирован для применения этого подхода! Почему? Эту тему