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

ЗАВИСИМОСТЬ И ДУБЛИРОВАНИЕ
Стив Фримен (Steve Freeman) указал, что проблема с
тестами и код ом заключается не в д ублировании (на которое я
еще не указал вам, но сд елаю это, как только закончится
отступление). Проблема заключается в зависимо сти межд у
код ом и тестами – вы не можете изменить од но, не изменив
д ругого. Наша цель – иметь возможно сть писать новые
о смысленные тесты, не меняя при этом код , что невозможно
при нашей текущей реализации.
Зависимо сть является ключевой проблемой разработки
программного обеспечения. Если фрагменты SQL, зависящие
от производ ителя используемой базы д анных, разбро саны по
всему код у и вы хотите поменять производ ителя, то
непременно окажется, что код зависит от этого производ ителя.
Вы не сможете поменять производ ителя базы д анных и при
этом не изменить код .
Зависимо сть является проблемой, а д ублирование – ее
симптомом. Чаще всего д ублирование проявляется в вид е
д ублирования логики – од но и то же выражение появляется в
различных частях код а. Объекты – отличный спо соб
абстрагирования, 
позволяющий 
избежать 
д анного 
вид а
д ублирования.
В отличие от большинства проблем в реальной жизни, гд е
устранение симптомов привод ит только к тому, что проблема
проявляется в худ шей форме гд е-то еще, устранение
д ублирования в программах устраняет и зависимо сть. Именно
поэтому 
существует 
второе 
правило 
TDD. 
Устраняя
д ублирование перед тем, как заняться след ующим тестом, мы
максимизируем наши шансы сд елать его успешным, внеся
всего од но изменение.

---

Мы выполнили первые четыре пункта цикла, и все готово к
устранению д ублирования. Но гд е же оно? Обычно мы замечаем
д ублирование в нескольких разных фрагментах код а, од нако в нашем
случае – д руг д руга д ублируют тест и тестируемый код . Еще не вид ите?
Как насчет того, чтобы написать так:
Dollar
int amount = 5 * 2;
Теперь ясно, откуд а мы взяли число 10. Вид имо, мы в уме произвели
умножение, причем так быстро, что д аже не заметили. Произвед ение «5
умножить на 2» присутствует как в тесте, так и в тестируемом код е.
Только изначально в код е оно было пред ставлено в вид е константы 10.
Сейчас же 5 и 2 отд елены д руг от д руга, и мы д олжны безжало стно
устранить д ублирование, перед тем как д винуться д альше. Такие вот
правила.
Действия, с помощью которого мы устранили бы 5 и 2 за од ин шаг,
не существует. Но что, если переместить установку поля (переменной)
amount в метод times()?
Dollar
int amount;
void times(int multiplier) {
amount= 5 * 2;
}
Тест все еще успешно выполняется, и инд икатор о стался зеленым.
Успех нам пока сопутствует.
Такие шаги кажутся вам слишком мелкими? Помните, TDD не
обязывает д вигаться только микро скопическими шагами, речь ид ет о
спо собно сти совершать эти микро скопические шаги. Буд у ли я
программировать д ень за д нем такими маленькими шагами? Нет. Но
когд а д ела совсем плохи, я рад возможно сти выполнять хоть такие
шаги. Примените микро скопические шаги к любому собственному
примеру. Если вы сможете прод вигаться маленькими шагами, вы сумеете
д елать шаги более крупного и под ход ящего размера. Если же вы
спо собны д елать только огромные шаги, вы никогд а не распознаете
ситуацию, в которой более уместны меньшие шаги.

---

Оставим рассужд ения. На чем мы о становились? Ну д а, мы
избавлялись от д ублирования межд у код ом теста и рабочим код ом. Гд е
мы можем взять 5? Это значение перед авало сь конструктору, поэтому
его можно сохранить в переменной amount: