Экстремальное программирование на примере денег

$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 принято активное управление риском. Мы не гонимся за совершенством. Выражая все двумя способами - тестами и кодом, - мы надеемся уменьшить дефекты настолько, чтобы уверенно идти дальше. Время от времени наши рассуждения будут нас подводить, позволяя появляться ошибкам. Когда это случится, мы вспомним урок о том, что надо написать тест и двигаться дальше. Все остальное время мы отважно продвигаемся вперед под победно развевающейся зеленой полоской нашего индикатора (вообще-то мой индикатор не развевается, но я люблю помечтать).

Подводя итоги, мы:

• использовали только что разработанную функциональность для улучшения теста;

• заметили, что если два теста проваливаются одновременно, то наши дела плохи;

• продолжили, несмотря на риск;

• использовали новую функциональность тестируемого объекта для уменьшения зависимости между тестами и кодом.


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=16879