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

 

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

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

Бек К. Экстремальное программирование: разработка через тестирование — СПб.: Питер, 2003. — 224 c.
ISBN 5-8046-0051-6
Скачать (прямая ссылка): bek-k..pdf
Предыдущая << 1 .. 7 8 9 10 11 12 < 13 > 14 15 16 17 18 19 .. 81 >> Следующая


}

Теперь нам уже не нужна вспомогательная переменная product, поэтому устраним ее:

public void testMultiplicationO { Dollar five= new Dollar(5): assertEquals(new Dollar(lO), five.times(2)): assertEquals(new Dollar(15), five.times(3)):

}

Согласитесь, этот вариант теста значительно нагляднее. Учтем внесенные изменения. Теперь только класс Dollar использует экземп-лярную переменную amount, поэтому мы можем сделать ее закрытой:

Dollar

private int amount;

$5 + 10 CHF = $10, если курс обмена 2:1 $5 * 2 - $10

Сделать переменную amount закрытым членом классо

Побочные эффекты d классе Dollar?

Округление денежных величин?

cquals()

hashCodeO

Равенство значению null Равенство объектов

Вычеркиваем еще один пункт из списка задач. Заметьте, мы подвергли себя риску: если тест для равенства не смог бы точно определить корректность операции сравнения, тогда и тест для умножения не смог бы проверить, правильно ли оно работает. В TDD принято активное управление риском. Мы не гонимся за совершенством. Выражая все двумя способами — тестами и кодом, — мы надеемся уменьшить дефекты настолько, чтобы уверенно идти дальше. Время от времени наши рассуждения будут нас подводить, позволяя появляться ошибкам. Когда это случится, мы вспомним урок о том, что надо написать тест и двигаться дальше. Все остальное время мы отважно продвигаемся вперед под победно развевающейся зеленой полоской нашего индикатора (вообще-то мой индикатор не развевается, но я люблю помечтать).

Подводя итоги, мы:

• использовали только что разработанную функциональность для улучшения теста;

• заметили, что если два теста проваливаются одновременно, то наши дела плохи;

• продолжили, несмотря на риск;

• использовали новую функциональность тестируемого объекта для уменьшения зависимости между тестами и кодом.

Поговорим о франках

$5 + 10 CHF = $10, если курс обмена 2:1 $5 * 2 - $10

Сделать переменную amount закрытым (private) членом

Побочные эффекты в классе Dollar?

Округление денежных величин?

equalsO

hashCodeO

Равенство значению null Равенство объектов 5 CHF * 2 = 10 CHF

Можем ли мы приступить к реализации первого, самого интересного теста в данном списке? Мне все еще кажется, что это будет слишком большой шаг. Я не представляю себе, каким образом можно написать этот тест за один маленький шажок. Мне кажется, что вначале необходимо создать объект наподобие Dollar, который соответствовал бы не долларам, а франкам. Пусть это будет объект с названием Franc. Для начала объект Franc может функционировать в точности так же, как и объект Dollar, — если у нас будет такой объект, нам будет проще размышлять о реализации теста, связанного со смешанным сложением двух разных валют.

А если объект Franc работает так же, как и объект Dollar, значит, мы можем просто скопировать и слегка отредактировать тест для объекта Dollar:

public void testFrancMultiplicationO { Franc five= new Franc(5): assertEquals(new Franc(lO). five.times(2)); assertEquals(new Franc(15), five.timesO)):

}

(Хорошо, что в главе 4 нам удалось упростить разработанный нами тест для Dollar. Благодаря этому работа по редактированию теста существенно упростилась. Похоже, в данной книге дела идут довольно гладко, однако я не могут гарантировать вам, что в будущем все будет так же хорошо.)

Franc(int amount) {

Теперь нам надо получить зеленую полоску. Какой способ будет самым простым? Проще всего скопировать код класса Dollar и заменить Dollar на Franc.

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

Если вам не по себе, глубоко вздохните через нос, досчитайте до трех и медленно выдохните через рот. Вам лучше? Теперь вспомните, что наш цикл состоит из пяти этапов. Иногда последовательное выполнение всех этапов занимает у нас всего несколько секунд, однако в любом случае мы обязательно выполняем каждый из них:

1. Написать тест.

2. Сделать так, чтобы тест откомпилировался.

3. Запустить тест и убедиться в том, что тест не сработал.

4. Сделать так, чтобы тест сработал.

5. Удалить дублирование.

На разных этапах решаются разные задачи, преследуются разные цели. То, что совершенно недопустимо для одного из этапов, может быть вполне приемлемым для другого этапа. Однако в целом методика TTD работает только в случае, если ни один из этапов не упущен. Если вы пропустите хотя бы одно звено, развалится вся цепочка.

Первые три фазы цикла разработки TTD должны выполняться как можно быстрее. Определяющая характеристика этих этапов — скорость. На этих этапах в жертву скорости можно принести очень многое, в том числе чистоту дизайна.

Честно говоря, сейчас я несколько волнуюсь. Я только что разрешил вам забыть о принципах хорошего дизайна. Представляю себе, как вы приходите к своим коллегам, подчиненным и во всеуслышание объявляете: «Кент сказал, что все эти разговоры про хороший дизайн — полная ерунда!» Остановитесь. Цикл еще не закончен. Четырехногий уродец из благородного семейства пятиногих стульев вечно падает. Первые четыре шага нашего цикла не работают без пятого. Хороший дизайн в подходящее время! Сначала сделаем, чтобы код заработал, потом сделаем, чтобы код был правильным (make it run, make it right).
Предыдущая << 1 .. 7 8 9 10 11 12 < 13 > 14 15 16 17 18 19 .. 81 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100