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

4. Данные должны быть закрытыми 
$5 + 1 °CHF = $10, если курс обмена 2:1
$5 * 2 = $10
Сделать переменную amount закрытым членом класса
Побочные эффекты в классе Dollar?
Округление д енежных величин?
equals()
hashCode()
Равенство значению null
Равенство объектов
Теперь, когд а опред елена операция проверки равенства, с ее
помощью можно повысить нагляд но сть тестов. По ид ее, метод
Dollar.times() д олжен возвращать новый объект Dollar, величина
которого равна величине исход ного объекта (метод которого мы
вызываем), умноженной на коэффициент. Од нако наш тест не
показывает этого явно:
public void testMultiplication() {
Dollar five = new Dollar(5);
Dollar product = five.times(2);
assertEquals(10, product.amount);
product = five.times(3);
assertEquals(15, product.amount);
}
Мы можем переписать первую проверку и сравнить в ней объекты
Dollar:
public void testMultiplication() {
Dollar five = new Dollar(5);
Dollar product = five.times(2);
assertEquals(new Dollar(10), product);
product = five.times(3);
assertEquals(15, product.amount);
}

---

Выгляд ит неплохо, поэтому перепишем и вторую проверку:
public void testMultiplication() {
Dollar five = new Dollar(5);
Dollar product = five.times(2);
assertEquals(new Dollar(10), product);
product = five.times(3);
assertEquals(new Dollar(15), product);
}
Теперь нам не нужна вспомогательная переменная product, поэтому
устраним ее:
public void testMultiplication() {
Dollar five= new Dollar(5);
assertEquals(new Dollar(10), five.times(2));
assertEquals(new Dollar(15), five.times(3));
}
Согласитесь, этот вариант теста значительно нагляд нее.
Учтем внесенные изменения. Теперь только класс Dollar использует
переменную экземпляра amount, поэтому мы можем сд елать ее закрытой:
Dollar
private int amount;
$5 + 1 °CHF = $10, если курс обмена 2:1
$5 * 2 = $10
Сд елать переменную amount закрытым членом класса
Побочные эффекты в классе Dollar?
Округление д енежных величин?
equals()
hashCode()
Равенство значению null
Равенство объектов
Вычеркиваем еще од ин пункт из списка зад ач. Заметьте, мы
под вергли себя риску: если тест, проверяющий равенство, не смог бы
точно опред елить корректно сть операции сравнения, тогд а и тест

---

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

---