Книга: Экстремальное программирование. Разработка через тестирование

Процесс

Цикл TDD выглядит следующим образом:

• написать тест;

• запустить все тесты и убедиться, что добавленный тест терпит неудачу;

• внести в код изменения;

• запустить тесты и убедиться, что все они выполнились успешно;

• выполнить рефакторинг, чтобы устранить дублирование.

Если исходить из того, что разработка теста – это один шаг, какое количество изменений требуется сделать, чтобы выполнить компиляцию, запуск и рефакторинг? (Под изменением я подразумеваю изменение определения метода или класса.) На рис. 17.2 показана гистограмма количества изменений для каждого из тестов «денежного» примера, над которым мы работали в первой части книги.

Рис. 17.2. Гистограмма количества изменений, приходящихся на каждый период рефакторинга

Я полагаю, что если бы мы собирали статистику для достаточно крупного проекта, мы обнаружили бы, что количество изменений, необходимых для компиляции и запуска кода, очень невелико (это количество можно уменьшить, если среда разработки будет понимать, что пытаются ей сказать тесты, и, например, автоматически добавлять в функциональный код необходимые заглушки). Однако количество изменений, вносимых в код во время рефакторинга, должно соответствовать (вот главный тезис) кривой распределения с эксцессом больше нормального, то есть с большим числом изменений, чем предсказывается стандартной кривой нормального распределения. Подобный профиль характерен для многих других естественных процессов, например для изменения стоимости акций на рынке ценных бумаг[9].

Оглавление книги