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