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

Триангуляция (Triangulate)
Какой самый консервативный спо соб позволяет формировать
абстракцию при помощи тестов? Делайте код абстрактным только в
случае, если у вас есть д ва или более примера.
Рассмотрим пример. Пред положим, мы хотим написать функцию,
которая возвращает сумму д вух целых чисел. Мы пишем:
public void testSum() {

---

assertEquals(4, plus(3, 1));
}
private int plus(int augend, int addend) {
return 4;
}
Чтобы получить пред ставление о правильном д изайне, мы
д обавляем еще од ин пример:
public void testSum() {
assertEquals(4, plus(3, 1));
assertEquals(7, plus(3, 4));
}
Теперь, когд а у нас есть еще од ин пример, мы можем сд елать
реализацию метод а plus() абстрактной:
private int plus(int augend, int addend) {
return augend + addend;
}
Триангуляция выгляд ит привлекательно, так как правила ее
выполнения вполне понятны. Правила д ля шаблона «Под д елка» (Fake It)
о снованы на ощущении д ублирования код а межд у тестом и
под д ельным код ом. Это ощущение может быть субъективным, поэтому
правила выгляд ят несколько туманными. Несмотря на то, что они
кажутся про стыми, правила триангуляции созд ают замкнутый цикл.
По сле того как мы написали д ва выражения assert и сформировали
абстрактную корректную реализацию метод а plus(), мы можем
уничтожить од но из выражений assert, так как теперь оно является
избыточным. А сд елав это, мы сможем упро стить реализацию plus(),
чтобы этот метод возвращал константу. По сле этого нам над о буд ет
снова д обавить выражение assert.
Я использую триангуляцию только в случае, если я д ействительно
не уверен, какая абстракция является корректной. В д ругих ситуациях я
пред почитаю использовать шаблон «Под д елка» (Fake It) или «Очевид ная
реализация» (Obvious Implementation).

---