Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Бек К. -> "Экстремальное программирование: разработка через тестирование " -> 30

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

Бек К. Экстремальное программирование: разработка через тестирование — СПб.: Питер, 2003. — 224 c.
ISBN 5-8046-0051-6
Скачать (прямая ссылка): bek-k..pdf
Предыдущая << 1 .. 24 25 26 27 28 29 < 30 > 31 32 33 34 35 36 .. 81 >> Следующая


т

о 25 — - ¦--—:—:-===—

g 20-- -1 1-===- -

1— —' —п— ~

* ю-- --- --, - —

5 -— -.- - - - -

о А—'—'—і—'—'—т—і—і—і—'-1—і—і—і—

0 1 < 5 < 10 >= 10

Количество минут между запусками

Рис. 17.1. Гистограмма интервалов времени между запусками тестов

Таблица 17.1. Метрики кода


Функциональный код
Тесты

Количество классов
5
1

Количество функций W
22
15

Количество строк кода (2)
91
89

Цикломатическая сложность кода (3'
1,04
1

Количество строк/Количество функций
4,1 W
5,9«

Вот некоторые примечания к данной таблице:

1. Мы не реализовали весь программный интерфейс (API) целиком, поэтому не можем достоверно оценить полное количество функций или количество функций на один класс или количество строк кода на один класс. Однако соотношения этих параметров можно считать поучительными. Количество функций и количество строк в тестах приблизительно такое же, как и в функциональном коде.

2. Количество строк кода в тестах можно сократить, если извлечь из кода общие фикстуры (fixtures). Однако общее соотношение между строками функционального кода и строками тестирующего кода при этом сохранится.

3. Цикломатическая сложность (cyclomatic complexity) — это величина, характеризующая сложность обычного потока управления в программе. Цикломатическая сложность тестов равна 1, так как в тестирующем коде нет ни ветвлений, ни циклов. Цикломатическая сложность функционального кода близка к единице, так как вместо явных ветвлений для передачи управления чаще используется полиморфизм.

4. Оценка количества строк в функции дана с учетом заголовка функции

и замыкающей скобки.

5. Количество строк на функцию для тестирующего кода в нашем случае больше чем могло бы быть, так как мы не выделили общего кода в виде фикстур. О фикстурах рассказывается в главе 29, которая посвящена методам работы с xUnit.

Процесс

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

• добавить небольшой тест;

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

Метрики кода

В табл. 17.1 сведены некоторые статистические данные о написанном коде.

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

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

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

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

10-

са 8'

о >.

м 6

со

о ш

5 4

T

s

I 2

t-41

А ДП| І А І І І І І І І І І І І І Iі

10 12 14 16 18 20 22 24 26 28 Количество изменений Рис. 17.2. Гистограмма количества изменений, приходящихся на каждый рефакторинг

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

Качество тестов

Тесты являются неотъемлемой частью методики TDD. Тесты TDD могут быть запущены в любое время работы над программой, а также после того, как про-

1 Mandelbrot, Benoit, ed. 1997. Fractals and Scaling in Finance. New York: Springer-Verlag.

грамма будет завершена. Однако не стоит путать их с другими важными типами тестирования:

• тестированием производительности;

• стрессовым тестированием;

• тестированием практичности.

Тем не менее если плотность вероятности дефектов в коде, разработанном с использованием TDD1 невелика, роль профессионального тестирования меняется. Если обычно профессиональное тестирование используется для постоянного надзора за работой программистов, то при использовании TDD профессиональное тестирование больше напоминает вспомогательный инструмент, облегчающий коммуникацию между теми, кто знает, как должна работать система, и теми, кто создает систему.

Как можно оценить качество разработанных нами тестов? Вот два широко распространенных метода:

• Покрытие операторов кода (statement coverage). Для оценки качества тестов этой характеристики недостаточно, однако ее можно использовать как отправную точку. Если программист ревностно следует всем требованиям TDD, покрытие функционального кода тестами должно составлять 100 %. Для оценки этой характеристики можно использовать специальные программные средства. Например, программа JProbe (www.sitaka.com/software/ jprobe) сообщает нам, что в нашем примере не покрытой тестами осталась всего одна строка в одном методе — Money.toString(). Напомню, что эта строка была добавлена в отладочных целях, фактически она не является функциональным кодом.
Предыдущая << 1 .. 24 25 26 27 28 29 < 30 > 31 32 33 34 35 36 .. 81 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100