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

Что не подлежит тестированию?
Флип пред ложил высказывание, которое может служить ответом на
этот вопро с: «Пишите тесты д о тех пор, пока страх не превратится в
скуку». Высказывание под разумевает, что вы д олжны найти ответ сами.
Од нако вы читаете эту книгу д ля того, чтобы найти в ней ответы на
вопро сы, поэтому попробуйте во спользоваться след ующим списком.
Тестировать след ует:
• условные операторы;
• циклы;
• операции;
• полиморфизм.
Од нако только те из них, которые вы написали сами. Не тестируйте
чужой код , если только у вас нет причин не д оверять ему. В некоторых
ситуациях нед о статки (можно сказать жестче: «ошибки») во внешнем
код е заставляют д обавлять д ополнительную логику в разрабатываемый
вами код . Над о ли тестировать под обное повед ение внешнего код а?
Иногд а я д окументирую непред сказуемое повед ение (ошибку) внешнего
код а при помощи теста, который перестанет выполняться, если в
след ующей версии внешнего код а ошибка буд ет исправлена.
Как определить качество тестов?
Тесты – это канарейка, которую берут в угольную шахту, чтобы по

---

ее повед ению опред елить присутствие запаха плохого д изайна. Далее
перечисляются некоторые атрибуты тестов, которые указывают на то,
что д изайн тестируемого код а начинает плохо пахнуть:
• Длинный код инициализации. Если вы вынужд ены написать сотни
строк код а, созд авая объекты д ля од ного про стого оператора assert(),
значит, что-то не так, значит, ваши объекты слишком большие и их
требуется разд елить.
• Дублирование код а инициализации. Если вы не можете быстро
найти общее место д ля общего код а инициализации, значит, у вас
слишком много объектов, которые слишком тесно взаимод ействуют
д руг с д ругом.
• Тесты выполняются слишком мед ленно. Если тесты TDD
работают слишком мед ленно, значит, они не буд ут запускаться
д о статочно часто. Значит, программист буд ет в течение некоторого
времени работать, вообще не запуская тестов. Значит, когд а он их все-
таки запустит, скорее всего, многие из них не сработают. На самом д еле
зд есь кроется серьезная проблема: если тесты работают мед ленно,
значит, 
тестирование 
частей 
и 
компонентов 
разрабатываемого
приложения связано с проблемами. Сложно сти при тестировании частей
и фрагментов приложения указывают на существование нед о статков
д изайна. Иными словами, улучшив д изайн, вы можете увеличить
скоро сть работы тестов. (Прод олжительно сть работы набора тестов не
д олжна превышать д есяти минут, по аналогии с ускорением свобод ного
пад ения в 9,8 м/с2. Если д ля выполнения набора тестов требуется более
10 минут, этот набор обязательно над о сократить или тестируемое
приложение д олжно быть оптимизировано так, чтобы д ля выполнения
набора тестов требовало сь не более 10 минут.)
• Хрупкие тесты. Если ваши тесты неожид анно начинают ломаться
в самых непред сказуемых местах, это означает, что од на часть
разрабатываемого приложения непред сказуемым образом влияет на
работу д ругой части. В этом случае необход имо улучшить д изайн так,
чтобы д анный эффект исчез. Для этого можно либо устранить связь
межд у частями приложения, либо объед инить д ве части воед ино.