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

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

---

как программа буд ет завершена. Од нако не стоит путать их с д ругими
важными типами тестирования:
• тестированием производ ительно сти;
• нагрузочным тестированием;
• тестированием уд обства использования.
Тем не менее, если плотно сть вероятно сти д ефектов в код е,
разработанном 
с 
использованием 
TDD, 
невелика, 
роль
профессионального 
тестирования 
меняется. 
Если 
обычно
профессиональное тестирование используется д ля по стоянного над зора
за 
работой 
программистов, 
то 
при 
использовании 
TDD
профессиональное тестирование больше напоминает вспомогательный
инструмент, облегчающий коммуникацию межд у теми, кто знает, как
д олжна работать система, и теми, кто созд ает систему.
Как можно оценить качество разработанных нами тестов? Вот д ва
широко распро страненных метод а:
Охват кода
(statement coverage). Для оценки качества тестов этой
характеристики нед о статочно, од нако ее можно использовать как
отправную точку. Если программист ревно стно след ует всем
требованиям TDD, тесты д олжны охватывать 100 % код а. Для оценки
этой характеристики можно использовать специальные программные
сред ства. Например, программа JProbe (www.sitaka.com/software/jprobe)
сообщает нам, что в нашем примере не охваченной тестами о сталась
всего од на строка в од ном метод е – Money.toString(). Напомню, что эта
строка была д обавлена в отлад очных целях, фактически она не является
функциональным код ом.
Намеренное добавление дефекта
(defect insertion). Это еще од ин
спо соб проверки качества тестов. Ид ея про ста: изменить значение
строки код а и убед иться, что тест перестал работать. Делать это можно
вручную или при помощи специального инструмента, такого как Jester
(jester.sourceforge.net). Этот инструмент сообщает нам, что в нашей
программе существует всего од на строка, которую можно изменить, не
нарушив работы тестов. Вот эта строка: Pair.hashCode(). Зд есь мы
про сто под д елали реализацию – вместо хеш-код а метод возвращает
по стоянное значение: 0. Если од но по стоянное значение заменить
д ругим, смысл программы не изменится (од на под д елка ничем не лучше
д ругой), поэтому под обную мод ификацию код а нельзя считать
д ефектом.
Флип, од ин из рецензентов моей книги, сообщил мне некоторые
д ополнительные 
соображения 
отно сительно 
охвата 
тестами.

---

Абсолютный показатель охвата вычисляется след ующим образом:
количество тестов, пред назначенных д ля тестирования различных
аспектов программы, необход имо разд елить на количество аспектов,
которые нужд аются в тестировании (сложно сть логики программы).
Существует д ва спо соба улучшить показатель охвата тестами. Во-
первых, можно написать больше тестов. Отсюд а разница в количестве
тестов, которые пишутся разработчиком, использующим TDD, и
профессиональным тестером. (В главе 32 привод ится пример зад ачи, д ля
решения которой я написал 6 тестов, а человек, профессионально
занимающийся тестированием, – 65 тестов.) Од нако существует и
д ругой спо соб улучшить охват – ограничиться фиксированным набором
тестов и упро стить логику программы. Под обный эффект зачастую
д о стигается в процессе рефакторинга – условные операторы заменяются
сообщениями классов или вовсе уд аляются из программы. Флип
выражает эту мысль так: «Вместо того чтобы увеличить количество
тестов и тем самым охватить всевозможные комбинации вход ных
д анных (говоря точнее, эффективное под множество всех комбинаций),
мы о ставляем количество тестов неизменным и меняем количество
внутренних структурных комбинаций код а».