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

$5 * 2 = $10

---

Сд елать переменную amount закрытым членом класса
Побочные эффекты в классе Dollar?
Округление д енежных величин?
Тест, который мы только что созд али, д аже не компилируется, но
это легко исправить. (О том, когд а и как созд аются тесты, я расскажу
позже – когд а мы буд ем под робнее говорить о сред е тестирования,
JUnit.) Как проще всего заставить тест компилироваться (пусть он пока и
буд ет терпеть неуд ачу)? У нас четыре ошибки компиляции:
• нет класса Dollar;
• нет конструктора;
• нет метод а times(int);
• нет поля (переменной) amount.
Устраним их од ну за д ругой. (Я всегд а ищу некоторую численную
меру прогресса.) От од ной ошибки мы избавимся, опред елив класс
Dollar:
Dollar
class Dollar
Од ной ошибкой меньше, о стало сь еще три. Теперь нам
понад обится конструктор, причем совершенно необязательно, чтобы он
что-то д елал – лишь бы компилировался.
Dollar
Dollar(int amount) {
}
Остало сь д ве ошибки. Необход имо созд ать заготовку метод а
times(). Снова мы выполним минимум работы, только чтобы заставить
тест компилироваться:
Dollar
void times(int multiplier) {
}
Теперь о сталась только од на ошибка. Чтобы от нее избавиться,
нужно созд ать поле (переменную) amount:

---

Dollar
int amount;
Отлично! Теперь можно запустить тест и убед иться, что он не
выполняется: ситуация прод емонстрирована на рис. 1.1.
Загорается зловещий красный инд икатор. Фреймворк тестирования
(JUnit в нашем случае) выполнил небольшой фрагмент код а, с которого
мы начали, и выяснил, что вместо ожид аемого результата «10»
получился «0». Ужасно…
Рис. 1.1.
Прогресс! Тест терпит неуд ачу
Вовсе нет! Неуд ача – это тоже прогресс. Теперь у нас есть
конкретная мера неуд ачи. Это лучше, чем про сто д огад ываться, что у
нас что-то не так. Наша зад ача «реализовать мультивалютно сть»
превратилась в «заставить работать этот тест, а потом заставить
работать все о стальные тесты». Так намного проще и намного меньше
повод ов д ля страха. Мы заставим этот тест работать.

---

Возможно, вам это не понравится, но сейчас наша цель не получить
ид еальное решение, а заставить тест выполняться. Мы принесем свою
жертву на алтарь истины и совершенства чуть позже.
Наименьшее 
изменение, 
которое 
заставит 
тест 
успешно
выполняться, пред ставляется мне таким:
Dollar
int amount = 10;
Рисунок 1.2 показывает результат повторного запуска теста. Теперь
мы вид им ту самую зеленую поло ску, во спетую в поэмах и
про славленную в веках.
Вот оно, счастье! Но рад оваться рано, вед ь цикл еще не завершен.
Уж слишком мал набор вход ных д анных, которые заставят такую
странно попахивающую и наивную реализацию работать правильно.
Перед тем как д вигаться д альше, немного поразмышляем.
Рис. 1.2.
Тест успешно выполняется

---

Вспомним, полный цикл TDD со стоит из след ующих этапов:
1. Добавить небольшой тест.
2. Запустить все тесты и убед иться, что новый тест терпит неуд ачу.
3. Внести небольшое изменение.
4. Снова запустить тесты и убед иться, что все они успешно
выполняются.
5. Устранить д ублирование с помощью рефакторинга.