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

Часть I 
На примере денег 
Мы займемся реализацией примера, разрабатывая код полно стью на
о снове тестирования (кроме случаев, когд а в учебных целях буд ут
д опускаться пред намеренные ошибки). Моя цель – д ать вам
почувствовать ритм разработки через тестирование (TDD). Кратко
можно сказать, что TDD заключается в след ующем:
• Быстро созд ать новый тест.
• Запустить все тесты и убед иться, что новый тест терпит неуд ачу.
• Внести небольшие изменения.
• Снова запустить все тесты и убед иться, что на этот раз все тесты
выполнились успешно.
• Провести рефакторинг д ля устранения д ублирования.
Кроме того, прид ется найти ответы на след ующие вопро сы:
• Как д обиться того, чтобы кажд ый тест охватывал небольшое
приращение функционально сти?
• Как и за счет каких небольших и, наверное, неуклюжих изменений
обеспечить успешное прохожд ение новых тестов?
• Как часто след ует запускать тесты?
• Из какого количества микро скопических шагов д олжен со стоять
рефакторинг?

---

1. Мультивалютные деньги 
Вначале мы рассмотрим объект, созд анный Уорд ом д ля системы
WyCash, – мультивалютные д еньги (см. «Введ ение»). Допустим, у нас
есть отчет врод е этого.
Добавив различные валюты, получим мультивалютный отчет.
Также необход имо указать курсы обмена.
$5 + 1 °CHF = $10, если курс обмена 2:1
$5 * 2 = $10
Что нам понад обится, чтобы сгенерировать такой отчет? Или,
д ругими словами, какой набор успешно выполняющихся тестов сможет
гарантировать, что созд анный код правильно генерирует отчет? Нам
понад обится:
• выполнять сложение величин в д вух различных валютах и
конвертировать результат с учетом указанного курса обмена;
• выполнять умножение величин в валюте (стоимо сть од ной акции)
на количество акций, результатом этой операции д олжна быть величина

---

в валюте.
Со ставим список зад ач, который буд ет напоминать нам о планах, не
д аст запутаться и покажет, когд а все буд ет готово. В начале работы над
зад ачей выд елим ее жирным шрифтом, 
вот так
. Закончив работу над ней
– вычеркнем, вот так. Когд а прид ет мысль написать новый тест,
д обавим новую зад ачу в наш список.
Как вид но из нашего списка зад ач, сначала мы займемся
умножением. Итак, какой объект понад обится нам в первую очеред ь?
Вопро с с под вохом. Мы начнем не с объектов, а с тестов. (Мне
приход ится по стоянно напоминать себе об этом, поэтому я про сто
притворюсь, что вы так же забывчивы, как и я.)
Попробуем снова. Итак, какой тест нужен нам в первую очеред ь?
Если исход ить из списка зад ач, первый тест пред ставляется д овольно
сложным. Попробуем начать с малого – умножение, – сложно ли его
реализовать? Займемся им д ля начала.
Когд а мы пишем тест, мы воображаем, что у нашей операции
ид еальный интерфейс. Попробуем пред ставить, как буд ет выгляд еть
операция снаружи. Конечно, наши пред ставления не всегд а буд ут
наход ить воплощение, но в любом случае стоит начать с наилучшего
возможного программного интерфейса (API) и при необход имо сти
вернуться назад , чем сразу д елать вещи сложными, урод ливыми и
«реалистичными».
Про стой пример умножения
[4 ]
:
public void testMultiplication() {
Dollar five = new Dollar(5);
five.times(2);
assertEquals(10, five.amount);
}
(Знаю, знаю: публичные поля, побочные эффекты, целые числа д ля
д енежных величин и все такое. Маленькие шаги – помните? Мы
отметим, что гд е-то есть д ушок
[5]
, и прод олжим д альше. У нас есть
тест, который не выполняется, и мы хотим как можно скорее увид еть
зеленую поло ску
[6]
.)
$5 + 1 °CHF = $10, если курс обмена 2:1