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

Часть I
На примере денег

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

• Быстро создать новый тест.

• Запустить все тесты и убедиться, что новый тест терпит неудачу.

• Внести небольшие изменения.

• Снова запустить все тесты и убедиться, что на этот раз все тесты выполнились успешно.

• Провести рефакторинг для устранения дублирования.

Кроме того, придется найти ответы на следующие вопросы:

• Как добиться того, чтобы каждый тест охватывал небольшое приращение функциональности?

• Как и за счет каких небольших и, наверное, неуклюжих изменений обеспечить успешное прохождение новых тестов?

• Как часто следует запускать тесты?

• Из какого количества микроскопических шагов должен состоять рефакторинг?

1. Мультивалютные деньги

Вначале мы рассмотрим объект, созданный Уордом для системы WyCash, – мультивалютные деньги (см. «Введение»). Допустим, у нас есть отчет вроде этого.

Добавив различные валюты, получим мультивалютный отчет.

Также необходимо указать курсы обмена.

$5 + 10 CHF = $10, если курс обмена 2:1

$5 * 2 = $10

Что нам понадобится, чтобы сгенерировать такой отчет? Или, другими словами, какой набор успешно выполняющихся тестов сможет гарантировать, что созданный код правильно генерирует отчет? Нам понадобится:

□ выполнять сложение величин в двух различных валютах и конвертировать результат с учетом указанного курса обмена;

□ выполнять умножение величин в валюте (стоимость одной акции) на количество акций, результатом этой операции должна быть величина в валюте.

Составим список задач, который будет напоминать нам о планах, не даст запутаться и покажет, когда все будет готово. В начале работы над задачей выделим ее жирным шрифтом, вот так. Закончив работу над ней – вычеркнем, вот так. Когда придет мысль написать новый тест, добавим новую задачу в наш список.

Как видно из нашего списка задач, сначала мы займемся умножением. Итак, какой объект понадобится нам в первую очередь? Вопрос с подвохом. Мы начнем не с объектов, а с тестов. (Мне приходится постоянно напоминать себе об этом, поэтому я просто притворюсь, что вы так же забывчивы, как и я.)

Попробуем снова. Итак, какой тест нужен нам в первую очередь? Если исходить из списка задач, первый тест представляется довольно сложным. Попробуем начать с малого – умножение, – сложно ли его реализовать? Займемся им для начала.

Когда мы пишем тест, мы воображаем, что у нашей операции идеальный интерфейс. Попробуем представить, как будет выглядеть операция снаружи. Конечно, наши представления не всегда будут находить воплощение, но в любом случае стоит начать с наилучшего возможного программного интерфейса (API) и при необходимости вернуться назад, чем сразу делать вещи сложными, уродливыми и «реалистичными». Простой пример умножения44
  Название метода times() можно перевести на русский как «умножить на». – Примеч. пер.


[Закрыть]:

public void testMultiplication() {

Dollar five = new Dollar(5);

five.times(2);

assertEquals(10, five.amount);

}

(Знаю, знаю: публичные поля, побочные эффекты, целые числа для денежных величин и все такое. Маленькие шаги – помните? Мы отметим, что где-то есть душок55
  Код с душком (code that smells) – распространенная в XP метафора, означающая плохой код (содержащий дублирование). – Примеч. пер.


[Закрыть], и продолжим дальше. У нас есть тест, который не выполняется, и мы хотим как можно скорее увидеть зеленую полоску66
  Имеется в виду индикатор успешного выполнения тестов в среде JUnit, имеющий форму полосы. Если все тесты выполнились успешно, полоса становится зеленой. Если хотя бы один тест потерпел неудачу, полоса становится красной. – Примеч. пер.


[Закрыть].)

$5 + 10 CHF = $10, если курс обмена 2:1

$5 * 2 = $10

Сделать переменную amount закрытым членом класса

Побочные эффекты в классе Dollar?

Округление денежных величин?

Тест, который мы только что создали, даже не компилируется, но это легко исправить. (О том, когда и как создаются тесты, я расскажу позже – когда мы будем подробнее говорить о среде тестирования, JUnit.) Как проще всего заставить тест компилироваться (пусть он пока и будет терпеть неудачу)? У нас четыре ошибки компиляции:

□ нет класса Dollar;

□ нет конструктора;

□ нет метода times(int);

□ нет поля (переменной) amount.

Устраним их одну за другой. (Я всегда ищу некоторую численную меру прогресса.) От одной ошибки мы избавимся, определив класс Dollar:

Dollar

class Dollar

Одной ошибкой меньше, осталось еще три. Теперь нам понадобится конструктор, причем совершенно необязательно, чтобы он что-то делал – лишь бы компилировался.

Dollar

Dollar(int amount) {

}

Осталось две ошибки. Необходимо создать заготовку метода times(). Снова мы выполним минимум работы, только чтобы заставить тест компилироваться:

Dollar

void times(int multiplier) {

}

Теперь осталась только одна ошибка. Чтобы от нее избавиться, нужно создать поле (переменную) amount:

Dollar

int amount;

Отлично! Теперь можно запустить тест и убедиться, что он не выполняется: ситуация продемонстрирована на рис. 1.1.

Загорается зловещий красный индикатор. Фреймворк тестирования (JUnit в нашем случае) выполнил небольшой фрагмент кода, с которого мы начали, и выяснил, что вместо ожидаемого результата «10» получился «0». Ужасно…

Рис. 1.1. Прогресс! Тест терпит неудачу

Вовсе нет! Неудача – это тоже прогресс. Теперь у нас есть конкретная мера неудачи. Это лучше, чем просто догадываться, что у нас что-то не так. Наша задача «реализовать мультивалютность» превратилась в «заставить работать этот тест, а потом заставить работать все остальные тесты». Так намного проще и намного меньше поводов для страха. Мы заставим этот тест работать.

Возможно, вам это не понравится, но сейчас наша цель не получить идеальное решение, а заставить тест выполняться. Мы принесем свою жертву на алтарь истины и совершенства чуть позже.

Наименьшее изменение, которое заставит тест успешно выполняться, представляется мне таким:

Dollar

int amount = 10;

Рисунок 1.2 показывает результат повторного запуска теста. Теперь мы видим ту самую зеленую полоску, воспетую в поэмах и прославленную в веках.

Вот оно, счастье! Но радоваться рано, ведь цикл еще не завершен. Уж слишком мал набор входных данных, которые заставят такую странно попахивающую и наивную реализацию работать правильно. Перед тем как двигаться дальше, немного поразмышляем.

Рис. 1.2. Тест успешно выполняется

Вспомним, полный цикл TDD состоит из следующих этапов:

1. Добавить небольшой тест.

2. Запустить все тесты и убедиться, что новый тест терпит неудачу.

3. Внести небольшое изменение.

4. Снова запустить тесты и убедиться, что все они успешно выполняются.

5. Устранить дублирование с помощью рефакторинга.

ЗАВИСИМОСТЬ И ДУБЛИРОВАНИЕ

Стив Фримен (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:

Dollar

Dollar(int amount) {

this.amount = amount;

}

и использовать в методе times():

Dollar

void times(int multiplier) {

amount = amount * 2;

}

Число 2 передается в параметре multiplier, поэтому подставим параметр вместо константы:

Dollar

void times(int multiplier) {

amount= amount * multiplier;

}

Чтобы продемонстрировать, как хорошо мы знаем синтаксис языка Java, используем оператор *= (который, кстати, уменьшает дублирование):

Dollar

void times(int multiplier) {

amount *= multiplier;

}

$5 + 10 CHF = $10, если курс обмена 2:1

$5 * 2 = $10

Сделать переменную amount закрытым членом класса

Побочные эффекты в классе Dollar?

Округление денежных величин?

Теперь можно пометить первый тест как завершенный. Далее мы позаботимся о тех странных побочных эффектах; но сначала давайте подведем итоги. Мы сделали следующее:

□ создали список тестов, которые – мы знаем – нам понадобятся;

□ с помощью фрагмента кода описали, какой мы хотим видеть нашу операцию;

□ временно проигнорировали особенности среды тестирования JUnit;

□ заставили тесты компилироваться, написав соответствующие заготовки;

□ заставили тесты работать, использовав сомнительные приемы;

□ слегка улучшили работающий код, заменив константы переменными;

□ добавили пункты в список задач, вместо того чтобы заняться всеми этими задачами сразу.

2. Вырождающиеся объекты

Обычный цикл разработки на основе тестирования состоит из следующих этапов:

1. Напишите тест. Представьте, как будет реализована в коде воображаемая вами операция. Продумав ее интерфейс, опишите все элементы, которые, как вам кажется, понадобятся.

2. Заставьте тест работать. Первоочередная задача – получить зеленую полоску. Если напрашивается простое и элегантное решение, используйте его. Если же на реализацию такого решения потребуется время, отложите его. Просто отметьте, что к нему нужно вернуться, когда будет решена основная задача – быстро получить зеленый индикатор. Такой подход довольно неприятен для опытных разработчиков (в эстетическом плане), ведь они следуют только правилам хорошей разработки. Но зеленая полоска прощает все грехи, правда, всего лишь на мгновение.

3. Улучшите решение. Теперь, когда система работает, избавьтесь от прошлых огрехов и вернитесь на путь истинной разработки. Устраните дублирование, которое вы внесли, и быстро сделайте так, чтобы полоска снова стала зеленой.

Наша цель – чистый код, который работает (отдельное спасибо Рону Джеффризу за этот слоган). Иногда такой код не по силам даже самым лучшим программистам, и почти всегда он не достижим для большинства программистов (вроде меня). Разделяй и властвуй, приятель, – в этом весь смысл! Сначала мы напишем код, «который работает», после чего создадим «чистый код». Такой подход противоречит модели разработки на основе архитектуры, в которой вы сначала пишете «чистый код», а потом мучаетесь, пытаясь интегрировать в проект код, «который работает».

$5 + 10 CHF = $10, если курс обмена 2:1

$5 * 2 = $10

Сделать переменную amount закрытым членом класса

Побочные эффекты в классе Dollar?

Округление денежных величин?

Мы получили один рабочий тест, но в процессе заметили нечто странное: при выполнении операции с объектом Dollar изменяется сам объект. Хотелось бы написать так:

public void testMultiplication() {

Dollar five = new Dollar(5);

five.times(2);

assertEquals(10, five.amount);

five.times(3);

assertEquals(15, five.amount);

}

Я не могу представить простого способа, который заставит этот тест выполняться.

После первого вызова метода times() пять уже больше не пять – на самом деле это уже десять. Если же метод 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.times():

Dollar

Dollar times(int multiplier) {

amount *= multiplier;

return null;

}

Теперь тест компилируется, но не работает. И это тоже прогресс! Чтобы заставить его работать, придется возвращать новый объект Dollar с правильным значением:

Dollar

Dollar times(int multiplier) {

return new Dollar(amount * multiplier);

}

$5 + 10 CHF = $10, если курс обмена 2:1

$5 * 2 = $10

Сделать переменную amount закрытым членом класса

Побочные эффекты в классе Dollar?

Округление денежных величин?

В главе 1, когда мы заставляли тест работать, мы начинали с заготовки и постепенно улучшали код, пока он не стал полноценным. Теперь мы написали сразу правильную реализацию и молились, пока выполнялись тесты (довольно короткие молитвы, честно говоря – выполнение тестов занимает миллисекунды). Нам повезло, тесты выполнились успешно, и мы вычеркнули еще один пункт.

Мне известны три способа быстрого получения зеленого индикатора. Вот первые два:

□ подделать реализацию, иначе говоря, создать заглушку, возвращающую константу, и постепенно заменять константы переменными до тех пор, пока не получится настоящий код;

□ использовать очевидную реализацию – просто написать сразу настоящую реализацию.

Используя TDD на практике, я периодически переключаюсь между двумя этими способами. Когда все идет гладко и я знаю, что делать, – я просто создаю одну за другой очевидные реализации (каждый раз запуская тесты, чтобы убедиться, что решение, очевидное для меня, также очевидно для компьютера). Как только я натыкаюсь на красный индикатор, я возвращаюсь к методике «поддельная реализация», после чего провожу рефакторинг. Когда уверенность возвращается, я снова использую методику «очевидная реализация».

Есть еще одна, третья методика, «Триангуляция» (Triangulation), которую мы рассмотрим в главе 3. Подведем итоги. Мы выполнили следующее:

□ сформулировали дефект проектирования (побочный эффект) в виде теста, который потерпел неудачу (из-за дефекта);

□ создали заглушку, обеспечившую быструю компиляцию кода;

□ заставили тест успешно выполняться, написав вроде бы правильный код.

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

3. Равенство для всех

Если у меня есть целое число и я прибавляю к нему 1, то не предполагаю, что изменится исходное число, – в результате я ожидаю получить новое число. Объекты же обычно ведут себя иначе. К примеру, если у меня есть контракт и я добавлю 1 к его сумме, это будет означать, что сумма контракта должна измениться (да, несомненно, это пример для обсуждения многих интересных законов бизнеса, которые мы здесь рассматривать не будем).

Мы можем использовать объекты в качестве значений, так же как используем наш объект Dollar. Соответствующий шаблон называется «Объект-значение» (Value Object). Одно из ограничений этого шаблона заключается в том, что значения атрибутов объекта устанавливаются в конструкторе и никогда в дальнейшем не изменяются.

Значительное преимущество использования шаблона «Объект-значение» состоит в том, что не нужно беспокоиться о проблеме наложения имен (aliasing). Скажем, у меня есть объект Check, представляющий собой чек, и я устанавливаю его сумму – $5, а затем присваиваю эти же $5 сумме другого объекта Check. Одна из самых неприятных проблем на моей памяти заключалась в том, что изменение суммы в первом объекте может приводить к непреднамеренному изменению суммы во втором. Это и есть проблема наложения имен.

Используя объекты-значения, не нужно беспокоиться о наложении имен. Если у меня есть пять долларов ($5), они всегда гарантированно будут оставаться именно пятью долларами ($5). Если вдруг кому-то понадобятся $7, придется создать новый объект.

$5 + 10 CHF = $10, если курс обмена 2:1

$5 * 2 = $10

Сделать переменную amount закрытым членом класса

Побочные эффекты в классе Dollar?

Округление денежных величин?

equals()

Одно из следствий использования шаблона «Объект-значение» заключается в том, что все операции должны возвращать результаты в виде новых объектов, как было показано в главе 2. Другое следствие заключается в том, что объекты-значения должны реализовывать метод equals(), операцию проверки равенства, потому что одни $5 ничем не отличаются от других.

$5 + 10 CHF = $10, если курс обмена 2:1

$5 * 2 = $10

Сделать переменную "amount" закрытым членом

Побочные эффекты в классе Dollar?

Округление денежных величин?

equals()

hashCode()

Кроме того, если использовать Dollar в качестве ключа хеш-таблицы, вместе с equals() придется реализовать и hashCode(). Добавим этот пункт в список задач и вернемся к нему, когда это будет необходимо.

Вы ведь не собираетесь немедленно приступать к реализации метода equals()? Отлично, я тоже об этом не думаю. Ударив себя линейкой по руке, я стал размышлять над тем, как протестировать равенство. Для начала $5 должны быть равны $5:

public void testEquality() {

assertTrue(new Dollar(5).equals(new Dollar(5)));

}

Полоска окрасилась красным. Поддельная реализация могла бы просто вернуть значение true:

Dollar

public boolean equals(Object object) {

return true;

}

Конечно, мы с вами знаем, что на самом деле true – это «5 == 5», что, в свою очередь, означает «amount == 5», что соответствует «amount == dollar.amount». Но если бы я сразу проследил все эти шаги, я не смог бы продемонстрировать третью и наиболее консервативную методику реализации – триангуляцию.

Если две станции слежения, находящиеся на известном расстоянии друг от друга, смогут измерить азимут некоторого источника радиосигнала (взять пеленг), этого вполне достаточно, чтобы вычислить местоположение источника радиосигнала (как вы помните из курса тригонометрии, в отличие от меня). Это вычисление и называется триангуляцией.

По аналогии, используя метод триангуляции, мы обобщаем код только в том случае, когда у нас два примера или больше. При этом мы ненадолго игнорируем дублирование между тестом и самим кодом (приложения). Когда второй пример потребует более общего решения, тогда и только тогда мы выполним обобщение.

Итак, для триангуляции нам понадобится второй пример. Как насчет того, чтобы проверить $5 != $6?

public void testEquality() {

assertTrue(new Dollar(5).equals(new Dollar(5)));

assertFalse(new Dollar(5).equals(new Dollar(6)));

}

Теперь необходимо обобщить равенство (equality):

Dollar

public boolean equals(Object object) {

Dollar dollar = (Dollar)object;

return amount == dollar.amount; }

$5 + 10 CHF = $10, если курс обмена 2:1

$5 * 2 = $10

Сделать переменную amount закрытым членом класса

Побочные эффекты в классе Dollar?

Округление денежных величин?

equals()

hashCode()

Мы могли бы использовать триангуляцию и для управления обобщением метода times(). Если бы у нас были примеры $5 * 2 = $10 и $5 * 3 = $15, нам не смогли бы просто возвращать константу.

Думаю, триангуляция – довольно интересная вещь. Я использую ее в случае, если не знаю, как выполнять рефакторинг. Если же я представляю, как устранить дублирование между кодом и тестами и создать более общее решение, я просто создаю его. С какой стати я должен создавать еще один тест, если сразу могу выполнить обобщение?

Однако когда когда в голову не приходит ничего умного, триангуляция дает шанс посмотреть на проблему с другой стороны. Сколько степеней свободы вы хотите поддерживать в вашем приложении (какую степень универсальности, другими словами)? Просто попробуйте ввести некоторые из них, и, возможно, ответ станет очевиднее.

$5 + 10 CHF = $10, если курс обмена 2:1

$5 * 2 = $10

Сделать переменную amount закрытым членом класса

Побочные эффекты в классе Dollar?

Округление денежных величин?

equals()

hashCode()

Равенство значению null

Равенство объектов

Итак, сейчас операция проверки равенства реализована полностью. Но как учесть сравнение со значением null и сравнение c другими объектами? Это часто используемые операции, пока они нам еще не нужны, поэтому мы просто добавим их в список задач.

Теперь, когда у нас есть операция проверки равенства, можно напрямую сравнивать объекты Dollar. Это позволит нам сделать переменную amount закрытой, какой и должна быть добропорядочная переменная экземпляра. Резюмируем все вышесказанное:

□ поняли, что для использования шаблона проектирования «Объект-значение» необходимо реализовать операцию проверки равенства;

□ создали тест для этой операции;

□ реализовали ее простейшим способом;

□ продолжили тестирование (вместо того, чтобы сразу приступить к рефакторингу);

□ выполнили рефакторинг так, чтобы охватить оба теста сразу.