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

Использование JUnit
Я поручил инфраструктуре JUnit вести журнал в процессе
разработки мультивалютного примера. Выяснило сь, что за все время я
нажал клавишу Enter ровно 125 раз. Оценку интервала межд у запусками
тестов нельзя считать д о стоверной, так как в ход е работы я не только

---

программировал, но и писал текст книги. Од нако когд а я занимался
только программированием, я запускал тесты приблизительно раз в
минуту.
На рис. 17.1 пред ставлена гистограмма интервалов межд у запусками
тестов. Большое количество д лительных интервалов, скорее всего,
обусловлено тем, что я тратил значительное время на написание текста
книги.
Рис. 17.1.
Гистограмма интервалов времени межд у запусками тестов
Метрики кода
В табл. 17.1 привод ятся некоторые статистические д анные,
характеризующие код .
Таблица 17.1.
Метрики код а

---

Вот некоторые примечания к д анной таблице:
1. Мы не реализовали весь программный интерфейс (API) целиком,
поэтому не можем д о стоверно оценить полное количество функций,
или количество функций на од ин класс, или количество строк код а на
од ин класс. Од нако соотношения этих параметров можно считать
поучительными. Количество функций и количество строк в тестах
приблизительно такое же, как и в функциональном код е.
2. Количество строк код а в тестах можно сократить, если извлечь из
код а 
операции 
под готовки 
тестовых 
д анных. 
Од нако 
общее
соотношение межд у строками функционального код а и строками
тестирующего код а при этом сохранится.
3. Цикломатическая сложно сть (cyclomatic complexity) – это
величина, характеризующая сложно сть обычного потока управления в
программе. Цикломатическая сложно сть тестов равна 1, так как в
тестирующем код е нет ни ветвлений, ни циклов. Цикломатическая
сложно сть функционального код а близка к ед инице, так как вместо
явных ветвлений д ля перед ачи управления чаще используется
полиморфизм.
4. Оценка количества строк в функции д ана с учетом заголовка
функции и закрывающей скобки.
5. Количество строк на функцию д ля тестирующего код а в нашем
случае больше чем могло бы быть, так как мы не выд елили общий код в
отд ельные функции. Об этом рассказывается в главе 29, которая
по священа метод ам работы с xUnit.
Процесс
Цикл TDD выгляд ит след ующим образом:
• написать тест;
• запустить все тесты и убед иться, что д обавленный тест терпит
неуд ачу;
• внести в код изменения;
• запустить тесты и убед иться, что все они выполнились успешно;
• выполнить рефакторинг, чтобы устранить д ублирование.
Если исход ить из того, что разработка теста – это од ин шаг, какое
количество 
изменений 
требуется 
сд елать, 
чтобы 
выполнить
компиляцию, запуск и рефакторинг? (Под изменением я под разумеваю

---

изменение опред еления метод а или класса.) На рис. 17.2 показана
гистограмма количества изменений д ля кажд ого из тестов «д енежного»
примера, над которым мы работали в первой части книги.