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

13. Делаем реализацию реальной

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

$5 + $5 = $10

Мы не можем вычеркнуть пункт $5 + $5, пока не удалим из кода все повторяющиеся фрагменты. Внимательно рассмотрим код. В нем нет повторяющегося кода, но есть повторяющиеся данные – $10 в «поддельной» реализации:

Bank

Money reduce(Expression source, String to) {

return Money.dollar(10);

}

Это выражение по своей сути дублирует выражение $5 + $5 в коде теста:

public void testSimpleAddition() {

Money five = Money.dollar(5);

Expression sum = five.plus(five);

Bank bank = new Bank();

Money reduced = bank.reduce(sum, "USD");

assertEquals(Money.dollar(10), reduced);

}

Раньше, если у нас имелась «поддельная» реализация, для нас было очевидным, как можно вернуться назад и сформировать реальную реализацию. Для этого достаточно было заменить константы переменными. Однако в данном случае пока не понимаю, как вернуться назад. Поэтому, несмотря на некоторый риск, я решаю двигаться вперед:

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Прежде всего, метод Money.plus() должен возвращать не просто объект Money, а реальное выражение (Expression), то есть сумму (Sum). (Возможно, в будущем мы оптимизируем специальный случай сложения двух одинаковых валют, однако это произойдет позже.)

Итак, в результате сложения двух объектов Money должен получиться объект класса Sum:

public void testPlusReturnsSum() {

Money five = Money.dollar(5);

Expression result = five.plus(five);

Sum sum = (Sum) result;

assertEquals(five, sum.augend);

assertEquals(five, sum.addend);

}

(Вы когда-нибудь слышали, что в английском языке первое слагаемое обозначается термином augend, а второе слагаемое – термином addend? Об этом не слышал даже автор до тех пор, пока не приступил к написанию данной книги.)

Только что написанный тест, скорее всего, проживет недолго. Дело в том, что он сильно связан с конкретной реализацией разрабатываемой нами операции и мало связан с видимым внешним поведением этой операции. Однако, заставив его работать, мы окажемся на шаг ближе к поставленной цели. Чтобы скомпилировать тест, нам потребуется класс Sum с двумя полями: augend и addend:

Sum

class Sum {

Money augend;

Money addend;

}

В результате получаем исключение преобразования классов (ClassCastException) – метод Money.plus() возвращает объект Money, но не объект Sum:

Money

Expression plus(Money addend) {

return new Sum(this, addend);

}

Класс Sum должен иметь конструктор:

Sum

Sum(Money augend, Money addend) {

}

Кроме того, класс Sum должен поддерживать интерфейс Expression:

Sum

class Sum implements Expression

Наша система компилируется, однако тесты терпят неудачу – это из-за того, что конструктор класса Sum не присваивает значений полям (мы могли бы создать «поддельную» реализацию, инициализировав поля константами, однако я обещал двигаться быстрее):

Sum

Sum(Money augend, Money addend) {

this.augend = augend;

this.addend = addend;

}

Теперь в метод Bank.reduce() передается объект класса Sum. Если суммируются две одинаковые валюты и целевая валюта совпадает с валютой обоих слагаемых, значит, результатом будет объект класса Money, чье значение будет равно сумме значений двух слагаемых:

public void testReduceSum() {

Expression sum = new Sum(Money.dollar(3), Money.dollar(4));

Bank bank = new Bank();

Money result = bank.reduce(sum, "USD");

assertEquals(Money.dollar(7), result);

}

Я тщательно выбираю значения параметров так, чтобы нарушить работу существующего теста. Когда мы приводим (метод reduce()) объект класса Sum к некоторой валюте, в результате (с учетом упомянутых упрощенных условий) должен получиться объект класса Money, чье значение (amount) совпадает с суммой значений двух объектов Money, переданных конструктору объекта Sum, а валюта (currency) совпадает с валютой обоих этих объектов:

Bank

Money reduce(Expression source, String to) {

Sum sum = (Sum) source;

int amount = sum.augend.amount + sum.addend.amount;

return new Money(amount, to);

}

Код выглядит уродливо по двум причинам:

□ мы выполняем приведение к типу Sum, в то время как код должен работать с любым объектом типа Expression;

□ мы используем общедоступные поля и два уровня ссылок на поля объектов.

Это достаточно легко исправить. Вначале переместим тело метода в класс Sum и благодаря этому избавимся от лишнего уровня ссылок:

Bank

Money reduce(Expression source, String to) {

Sum sum = (Sum) source;

return sum.reduce(to);

}

Sum

public Money reduce(String to) {

int amount = augend.amount + addend.amount;

return new Money(amount, to);

}

На секундочку заглянем в будущее. Приведение (reduce) суммы к некоторой валюте не может быть выполнено, если объект Sum не знает об обменном курсе. Однако обменный курс хранится в классе Bank, значит, скорее всего, в будущем нам потребуется передавать в метод Sum.reduce() еще один параметр типа Bank. Однако сейчас наш код не требует этого. Поэтому мы не добавляем никаких лишних параметров, чтобы лишний раз в них не путаться. (Что касается меня, то искушение было столь велико, что я все-таки добавил этот параметр, когда в первый раз писал данный код, – мне очень, очень стыдно.)

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Так, а что же происходит в случае, если аргументом метода Bank.reduce() является объект Money?

Давайте напишем тест, слава богу, перед нами зеленая полоса и мы не видим каких-либо других очевидных способов модификации кода:

public void testReduceMoney() {

Bank bank = new Bank();

Money result = bank.reduce(Money.dollar(1), "USD");

assertEquals(Money.dollar(1), result);

}

Bank

Money reduce(Expression source, String to) {

if (source instanceof Money) return (Money) source;

Sum sum= (Sum) source;

return sum.reduce(to);

}

Какой кошмар! Отвратительно! Тем не менее мы получили зеленую полоску и можем приступать к рефакторингу. Прежде всего, вместо прямой проверки класса всегда следует использовать полиморфизм. Класс Sum реализует метод reduce(String), и, если этот метод добавить в класс Money, мы сможем включить reduce(String) в состав интерфейса Expression.

Bank

Money reduce(Expression source, String to) {

if (source instanceof Money)

return (Money) source.reduce(to);

Sum sum = (Sum) source;

return sum.reduce(to);

}

Money

public Money reduce(String to) {

return this;

}

Включаем метод reduce(String) в состав интерфейса Expression:

Expression

Money reduce(String to);

Теперь можно избавиться от этих уродливых операций приведения типа и проверок классов:

Bank

Money reduce(Expression source, String to) {

return source.reduce(to);

}

Я не вполне доволен ситуацией, когда в интерфейсе Expression и классе Bank присутствуют методы с одинаковыми именами, но с разным набором параметров. Я так и не смог найти приемлемого решения этой проблемы в Java. В языках, где поддерживаются ключевые параметры, разница между методами Bank.reduce(Expression, String) и Expression.reduce(String) делается очевидной благодаря синтаксису языка. Однако в языках, в которых различие параметров определяется различием их позиций в списке параметров, разница между двумя подобными методами становится менее очевидной.

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

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

В данной главе мы

□ не отметили тест как завершенный, так как не избавились от дублирования;

□ чтобы прояснить реализацию, решили двигаться вперед вместо того, чтобы двигаться назад;

□ написали тест, чтобы форсировать создание объекта, который, как нам кажется, потребуется в будущем (объект класса Sum);

□ ускорили процесс реализации (конструктор класса Sum);

□ реализовали код с приведением типов в одном месте, добились успешного выполнения тестов, а затем переместили код туда, где он должен находиться;

□ использовали полиморфизм, чтобы избавиться от явной проверки типа (класса).

14. Обмен валюты

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

Изменения, перемены, обмены – их объятия заслуживают внимания (особенно если у вас есть книга с фразой в заголовке «в объятиях изменений» (embrace change))88
  Используя игру слов (английское change означает как «изменение», так и «обмен»), автор намекает на свою знаменитую книгу-бестселлер Extreme Programming Explained: Embrace Change. Русский перевод: Бек К. Экстремальное программирование. СПб.: Питер, 2002. 224 с. – Примеч. ред.


[Закрыть] Впрочем, нас заботит простейшая форма обмена – у нас есть два франка и мы хотим получить один доллар. Это звучит как готовый тест:

public void testReduceMoneyDifferentCurrency() {

Bank bank = new Bank();

bank.addRate("CHF", "USD", 2);

Money result = bank.reduce(Money.franc(2), "USD");

assertEquals(Money.dollar(1), result);

}

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

Money

public Money reduce(String to) {

int rate = (currency.equals("CHF") && to.equals("USD"))

? 2

: 1;

return new Money(amount / rate, to);

}

Получается, что класс Money знает о курсе обмена. Это неправильно. Единственным местом, в котором выполняются любые операции, связанные с курсом обмена, должен быть класс Bank. Мы должны передать параметр типа Bank в метод Expression.reduce(). (Вот видите? Мы так и думали, что нам это потребуется. И мы оказались правы.) Вначале меняем вызывающий код:

Bank

Money reduce(Expression source, String to) {

return source.reduce(this, to);

}

Затем меняем код реализаций:

Expression

Money reduce(Bank bank, String to);

Sum

public Money reduce(Bank bank, String to) {

int amount = augend.amount + addend.amount;

return new Money(amount, to);

}

Money

public Money reduce(Bank bank, String to) {

int rate = (currency.equals("CHF") && to.equals("USD"))

? 2

: 1;

return new Money(amount / rate, to);

}

Методы должны быть общедоступными (public), так как все методы интерфейсов должны быть общедоступными (я надеюсь, можно не объяснять, почему).

Теперь мы можем вычислить курс обмена внутри класса Bank:

Bank

int rate(String from, String to) {

return (from.equals("CHF") && to.equals("USD"))

? 2

: 1;

}

И обратиться к объекту bank с просьбой предоставить значение курса обмена:

Money

public Money reduce(Bank bank, String to) {

int rate = bank.rate(currency, to);

return new Money(amount / rate, to);

}

Эта надоедливая цифра 2 снова отсвечивает как в разрабатываемом коде, так и в теле теста. Чтобы избавиться от нее, мы должны создать таблицу обменных курсов в классе Bank и при необходимости обращаться к этой таблице для получения значения обменного курса. Для этой цели мы могли бы воспользоваться хеш-таблицей, которая ставит в соответствие паре валют соответствующий обменный курс. Можем ли мы в качестве ключа использовать двухэлементный массив, содержащий в себе две валюты? Проверяет ли метод Array.equals() эквивалентность элементов массива?

public void testArrayEquals() {

assertEquals(new Object[] {"abc"}, new Object[] {"abc"});

}

Нет. Тест провалился. Придется создавать специальный объект, который будет использоваться в качестве ключа хеш-таблицы:

Pair

private class Pair {

private String from;

private String to;

Pair(String from, String to) {

this.from = from;

this.to = to;

}

}

Мы планируем использовать объекты Pair в качестве ключей, поэтому нам необходимо реализовать методы equals() и hashCode(). Я не собираюсь писать для этого тесты, так как мы разрабатываем код в контексте рефакторинга. Дело в том, что от работоспособности этого кода жестко зависит успешное выполнение существующих тестов. Если код работает неправильно, существующие тесты потерпят неудачу. Однако если бы я программировал в паре с кем-то, кто плохо представлял бы себе направление дальнейшего движения, или если бы логика кода была более сложной, я несомненно приступил бы к разработке специальных тестов.

Pair

public boolean equals(Object object) {

Pair pair = (Pair) object;

return from.equals(pair.from) && to.equals(pair.to);

}

public int hashCode() {

return 0;

}

0 – ужасное хеш-значение, однако такой метод хеширования легко реализовать, стало быть, мы быстрее получим работающий код. Поиск валюты будет осуществляться простым линейным перебором. Позже, когда у нас будет множество валют, мы сможем тщательнее проработать этот вопрос, использовав реальные данные.

Теперь нам нужно место, в котором мы могли бы хранить значения обменных курсов:

Bank

private Hashtable rates= new Hashtable();

Нам также потребуется метод добавления нового курса обмена:

Bank

void addRate(String from, String to, int rate) {

rates.put(new Pair(from, to), new Integer(rate));

}

И метод, возвращающий обменный курс:

Bank

int rate(String from, String to) {

Integer rate = (Integer) rates.get(new Pair(from, to));

return rate.intValue();

}

Подождите-ка минутку! Перед нами красная полоса. Что случилось? Взглянув на код, мы видим, что проблема в неправильном значении курса при обмене доллара на доллары. Мы ожидаем, что при обмене USD на USD курс обмена будет равен 1, однако на текущий момент это не так. Поскольку эта ситуация стала для нас сюрпризом, оформим ее в виде дополнительного теста:

public void testIdentityRate() {

assertEquals(1, new Bank().rate("USD", "USD"));

}

Теперь у нас три ошибки, однако все они могут быть исправлены при помощи одного небольшого изменения:

Bank

int rate(String from, String to) {

if (from.equals(to)) return 1;

Integer rate = (Integer) rates.get(new Pair(from, to));

return rate.intValue();

}

Зеленая полоска!

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

Далее мы переходим к нашему последнему, самому большому тесту, $5 + 10 CHF. В данной главе мы применили несколько важных технологий:

□ добавили параметр, который может нам понадобиться;

□ удалили дублирование между кодом и тестами;

□ написали тест (testArrayEquals), чтобы проверить порядок функционирования встроенной операции Java;

□ создали вспомогательный закрытый (private) класс, не обладающий собственными тестами;

□ допустили ошибку при рефакторинге и написали еще один тест, чтобы изолировать проблему.

15. Смешение валют

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

Теперь мы готовы написать тест, с которого все началось, – $5 + 10 CHF:

public void testMixedAddition() {

Expression fiveBucks = Money.dollar(5);

Expression tenFrancs = Money.franc(10);

Bank bank = new Bank(); bank.addRate("CHF", "USD", 2);

Money result = bank.reduce(fiveBucks.plus(tenFrancs), "USD");

assertEquals(Money.dollar(10), result);

}

Именно такой код нам хотелось бы написать. К сожалению, мы сразу же получаем кучу ошибок компиляции. Обобщая код в процессе перехода от Money к Expression, мы оставили много висящих хвостов, на которые я, конечно же, обратил внимание, но решил вас не беспокоить. Теперь настало время заняться устранением дефектов.

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

public void testMixedAddition() {

Money fiveBucks = Money.dollar(5);

Money tenFrancs = Money.franc(10);

Bank bank = new Bank();

bank.addRate("CHF", "USD", 2);

Money result = bank.reduce(fiveBucks.plus(tenFrancs), "USD");

assertEquals(Money.dollar(10), result);

}

Тест терпит неудачу. Мы получаем 15 USD вместо 10 USD. Дело в том, что метод Sum.reduce() не выполняет приведение аргументов:

Sum

public Money reduce(Bank bank, String to) {

int amount = augend.amount + addend.amount;

return new Money(amount, to);

}

Если выполнить приведение обоих аргументов, тест должен сработать:

Sum

public Money reduce(Bank bank, String to) {

int amount= augend.reduce(bank, to).amount

+ addend.reduce(bank, to).amount;

return new Money(amount, to);

}

И действительно, тест срабатывает. Теперь мы можем заменить тип Money на тип Expression. Чтобы избежать взаимовлияний, мы начнем издалека и будем двигаться в направлении тестирующего кода. Итак, поля augend и addend теперь могут иметь тип Expression:

Sum

Expression augend;

Expression addend;

Аргументы конструктора тоже могут иметь тип Expression:

Sum

Sum(Expression augend, Expression addend) {

this.augend = augend;

this.addend = addend;

}

(Класс Sum начинает напоминать мне шаблон «Компоновщик» (Composite), однако еще не настолько, чтобы я захотел обобщить его.) С классом Sum, пожалуй, закончили, а что насчет Money?

Аргумент метода plus() может иметь тип Expression:

Money

Expression plus(Expression addend) {

return new Sum(this, addend);

}

Метод times() может возвращать значение типа Expression:

Money

Expression times(int multiplier) {

return new Money(amount * multiplier, currency);

}

Это означает, что операции plus() и times() должны входить в состав интерфейса Expression. С классом Money закончили. Теперь можно изменить аргументы метода plus() в реализации теста:

public void testMixedAddition() {

Money fiveBucks = Money.dollar(5);

Expression tenFrancs = Money.franc(10);

Bank bank = new Bank();

bank.addRate("CHF", "USD", 2);

Money result = bank.reduce(fiveBucks.plus(tenFrancs), "USD");

assertEquals(Money.dollar(10), result);

}

Объект tenFrancs теперь принадлежит типу Expression, а это значит, что мы должны внести в код некоторые изменения. К счастью, компилятор подсказывает нам, что именно мы должны сделать. Прежде всего вносим изменение:

public void testMixedAddition() {

Expression fiveBucks = Money.dollar(5);

Expression tenFrancs = Money.franc(10);

Bank bank = new Bank();

bank.addRate("CHF", "USD", 2);

Money result = bank.reduce(fiveBucks.plus(tenFrancs), "USD");

assertEquals(Money.dollar(10), result);

}

Компилятор вежливо сообщает, что plus() не является методом интерфейса Expression. Добавим этот метод в интерфейс:

Expression

Expression plus(Expression addend);

Теперь мы должны добавить этот метод в классы Money и Sum. Money? Да, этот метод должен быть открытым (public) в классе Money:

Money

public Expression plus(Expression addend) {

return new Sum(this, addend);

}

Что касается класса Sum, просто добавим заглушку и отметим необходимость реализации этого метода в списке задач:

Sum

public Expression plus(Expression addend) {

return null;

}

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

Sum.plus

Expression.times

Теперь программа компилируется и все тесты выполняются успешно.

Мы готовы завершить обобщение класса Money до Expression, но прежде, как всегда, подведем краткий итог. В этой главе мы

□ за один шаг написали необходимый тест и затем модифицировали его, чтобы добиться успешного его выполнения;

□ выполнили обобщение (использовали более абстрактное объявление);

□ воспользовались подсказками компилятора, чтобы внести изменения (Expression fiveBucks), которые привели к необходимости дополнительных изменений (добавление метода plus() в интерфейс Expression и т. п.).

16. Абстракция, наконец-то!

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

Sum.plus

Expression.times

Чтобы завершить добавление метода Expression.plus, мы должны реализовать метод Sum.plus(). Затем нам останется добавить метод Expression.times(), и мы сможем считать пример завершенным. Вот тест для метода Sum.plus():

public void testSumPlusMoney() {

Expression fiveBucks = Money.dollar(5);

Expression tenFrancs = Money.franc(10);

Bank bank = new Bank();

bank.addRate("CHF", "USD", 2);

Expression sum = new Sum(fiveBucks, tenFrancs).plus(fiveBucks);

Money result = bank.reduce(sum, "USD");

assertEquals(Money.dollar(15), result);

}

Мы могли бы создать объект Sum путем сложения fiveBucks и tenFrancs, однако приведенный код, который явно создает объект Sum, выглядит более понятным. Ведь мы пишем эти тесты не только ради удовольствия от программирования, но также для того, чтобы будущие поколения программистов могли оценить нашу гениальность. Однако они не смогут сделать этого, если код будет непонятным. Поэтому, разрабатывая любой код, думайте о тех, кто будет его читать.

В данном случае код теста длиннее, чем сам тестируемый код. Код точно такой же, как код в классе Money (кажется, я уже предвижу необходимость создания абстрактного класса):

Sum

public Expression plus(Expression addend) {

return new Sum(this, addend);

}

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

Sum.plus

Expression.times

При использовании TDD вы часто будете сталкиваться с тем, что количество строк в тестовом коде будет приблизительно таким же, как и количество строк в тестируемом коде. Чтобы методика TDD обладала экономическим смыслом, вы должны либо записывать в два раза большее количество строк кода, чем обычно, либо реализовывать ту же самую функциональность при помощи количества строк, в два раза меньшего, чем обычно. Эти показатели рекомендуется оценить самостоятельно на примере собственной практики. Однако, выполняя оценку, вы должны принять во внимание время, которое тратится на отладку, интеграцию и объяснение внутреннего устройства другим людям.

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

Sum.plus

Expression.times

Если мы получили работающий метод Sum.times(), значит, объявление Expression.times() не составит для нас труда. Вот соответствующий тест:

public void testSumTimes() {

Expression fiveBucks = Money.dollar(5);

Expression tenFrancs = Money.franc(10);

Bank bank = new Bank();

bank.addRate("CHF", "USD", 2);

Expression sum = new Sum(fiveBucks, tenFrancs).times(2);

Money result = bank.reduce(sum, "USD");

assertEquals(Money.dollar(20), result);

}

И снова тест получился длиннее тестируемого кода. (Те, кто достаточно много работал с JUnit, должно быть уже догадались, как решить эту проблему. Остальным я рекомендую прочитать раздел «Fixture (Фикстура)» в главе 29, посвященной шаблонам xUnit.)

Sum

Expression times(int multiplier) {

return new Sum(augend.times(multiplier),addend.times(multiplier));

}

В предыдущей главе мы изменили тип переменных augend и addend на Expression, поэтому теперь, чтобы скомпилировать код, нам необходимо добавить в интерфейс Expression метод times():

Expression

Expression times(int multiplier);

При этом нам следует изменить режим видимости методов Money.times() и Sum.times() (они должны стать общедоступными):

Sum

public Expression times(int multiplier) {

return new Sum(augend.times(multiplier),addend.times(multiplier));

}

Money

public Expression times(int multiplier) {

return new Money(amount * multiplier, currency);

}

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

Sum.plus

Expression.times

Все заработало.

Осталось провести эксперимент для случая, когда в результате выполнения операции $5 + $5 получается объект Money. Вот соответствующий тест:

public void testPlusSameCurrencyReturnsMoney() {

Expression sum = Money.dollar(1).plus(Money.dollar(1));

assertTrue(sum instanceof Money);

}

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

Money

public Expression plus(Expression addend) {

return new Sum(this, addend);

}

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

$5 + $5 = $10

Операция $5 + $5 возвращает объект Money

Bank.reduce(Money)

Приведение объекта Money с одновременной конверсией валют

Reduce(Bank,String)

Sum.plus

Expression.times

Не существует очевидного и ясного способа проверить валюту аргумента, если этот аргумент является объектом класса Money (по крайней мере, я не могу найти такого способа, однако вы можете над этим подумать). Эксперимент окончился неудачей, мы удаляем тест (который нам все равно не нравился).

Подводим итог. Мы

□ написали тест так, чтобы его смысл легко был понят другими программистами, которые в будущем будут читать разработанный нами код;

□ наметили эксперимент, призванный сравнить эффективность TDD по отношению к обычному стилю программирования, используемому вами на текущий момент;

□ снова столкнулись с необходимостью изменения множества объявлений в разрабатываемом коде и снова воспользовались услугами компилятора, чтобы исправить все неточности;

□ попробовали провести быстрый эксперимент, однако отказались от идеи, так как она не сработала, и уничтожили соответствующий тест.