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

Охват кода (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 тестов.) Однако существует и другой способ улучшить охват – ограничиться фиксированным набором тестов и упростить логику программы. Подобный эффект зачастую достигается в процессе рефакторинга – условные операторы заменяются сообщениями классов или вовсе удаляются из программы. Флип выражает эту мысль так: «Вместо того чтобы увеличить количество тестов и тем самым охватить всевозможные комбинации входных данных (говоря точнее, эффективное подмножество всех комбинаций), мы оставляем количество тестов неизменным и меняем количество внутренних структурных комбинаций кода».

Последний взгляд назад

Существует три важных навыка, которые необходимо освоить тем, кто впервые изучает TDD:

• три основных подхода, которые используются, чтобы заставить тест работать: подделка реализации, триангуляция и очевидная реализация;

• устранение дублирования между функциональным кодом и тестами – важный способ формирования дизайна;

• способность контролировать расстояние между тестами: когда дорога становится скользкой, необходимо двигаться маленькими шажками; когда дальнейший путь ясен, можно увеличить скорость.

Часть II На примере xUnit

Какой подход использовать при создании инструмента для разработки через тестирование? Естественно, разработку через тестирование.

Архитектура xUnit хорошо реализуется на языке Python, поэтому во второй части книги я перейду на использование Python. Не беспокойтесь, для тех, кто никогда раньше не имел дела с Python, я добавлю в текст необходимые пояснения. Когда вы прочитаете вторую часть, вы, во-первых, освоите базовые навыки программирования на Python, во-вторых, узнаете, как самому разработать свою собственную инфраструктуру для автоматического тестирования, и, в-третьих, ознакомитесь с более сложным примером использования методики TDD – три по цене одного!

18. Первые шаги на пути к xUnit

Разработка инструмента тестирования с использованием самого этого инструмента для тестирования многим может показаться чем-то, напоминающим хирургическую операцию на своем собственном мозге. («Только не вздумай трогать центры моторики! О! Слишком поздно! Игра окончена».) Сначала эта идея может показаться жутковатой. Однако инфраструктура тестирования обладает более сложной внутренней логикой, если сравнивать с относительно несложным денежным примером, рассмотренным в первой части книги. Часть II можно рассматривать как шаг в сторону разработки «настоящего» программного обеспечения. Кроме того, вы можете рассматривать этот материал как упражнение в самодокументируемом программировании.