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

Franc
Money times(int multiplier) {
return new Franc(amount * multiplier, 
currency
);
}
Сработало! Теперь тот же трюк можно прод елать и в отношении
класса Dollar:
Dollar
Money times(int multiplier) {
return new Dollar(amount * multiplier,
currency
);
}
Мы почти закончили. Имеет ли значение, что мы используем в
д анном случае – Franc или Money? Об этом можно рассужд ать в течение
некоторого времени исход я из имеющихся знаний о внутреннем
устройстве нашей системы, од нако у нас есть чистый код и тесты,
которые д ают нам уверенно сть в том, что код работает так, как над о.
Вместо того чтобы тратить несколько минут на рассужд ения, мы можем
спро сить об этом компьютер. Для этого д о статочно внести

---

интересующие нас изменения в код и запустить тесты. Обучая метод ике
TDD, я наблюд аю под обную ситуацию по стоянно – опытные умные
программисты тратят от 5 д о 10 минут на обсужд ение вопро са, на
который компьютер может д ать ответ в течение 15 секунд . Если у вас
нет тестов, вам о стается только размышлять и пред полагать. Если же у
вас есть тесты, вместо того, чтобы напрасно тратить время, вы можете
провести быстрый эксперимент. Как правило, если у вас есть тесты,
быстрее спро сить компьютер.
Чтобы провести интересующий нас эксперимент, мод ифицируем
код так, чтобы метод Franc.times() возвращал значение типа Money:
Franc
Money times(int multiplier) {
return new 
Money
(amount * multiplier, currency);
}
В ответ компилятор сообщил, что Money д олжен быть конкретным
(не абстрактным) классом:
Money
class Money
Money times(int amount) {
return null;
}
Получаем красную поло ску и сообщение об ошибке: «expected:
but was:». Не очень-то
информативно. Не так информативно, как нам хотело сь бы. Чтобы
получить более о смысленное сообщение об ошибке, д обавим метод
toString():
Money
public String toString() {
return amount + " " + currency;
}
О, ужас! Код без тестов?! Допустимо ли такое? Конечно же, прежд е
чем писать код метод а toString, мы д олжны были написать
соответствующий тест, од нако

---

• мы увид им результаты работы этого метод а на экране;
• метод toString() используется только д ля отлад ки, поэтому риск,
связанный с потенциальными ошибками, невелик;
• перед нами красная поло са, а мы пред почитаем не писать новых
тестов, пока не избавимся от красной поло сы.
Обстоятельства приняты к свед ению.
Теперь сообщение об ошибке изменило сь: "expected:<1 °CHF> but
was:<1 °CHF>". Выгляд ит о смысленней, од нако сбивает с толку. В д вух
объектах хранятся од ни и те же д анные, од нако при этом объекты не
считаются равными. Проблема кроется в реализации метод а equals():
Money
public boolean equals(Object object) {
Money money = (Money) object;
return amount == money.amount
&& getClass(). equals(money.getClass());
}
В д анном случае происход ит сравнение имен классов, в то время как
логичнее сравнивать ид ентификаторы валют.
Лучше не писать никаких новых тестов, если перед вами красная
поло са. Од нако нам нужно внести изменения в разрабатываемый код , и
мы не можем изменить код , не облад ая соответствующим тестом.
Консервативный под ход заключается в том, чтобы отменить изменение,
которое привело к появлению красной поло сы. В этом случае мы вновь
получим зеленую поло су. По сле этого мы сможем мод ифицировать тест
д ля метод а equals(), исправить его реализацию и вновь применить
изначальное изменение.
В д анном случае мы буд ем д ействовать консервативно. (Иногд а я
плюю на все и пишу тест, не обращая внимания на красную поло су,
од нако я по ступаю так, только когд а д ети уже спят.)