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

Какой следующий тест лучше всего выбрать из списка задач для реализации? Выбирайте тест, который, во-первых, научит вас чему-либо, а во-вторых, который вы сможете реализовать.

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

плюс;

минус;

умножение;

деление;

сложение с такой же валютой;

равенство;

равенство нулю;

нулевой обмен;

обмен одной и той же валюты;

обмен двух валют;

курс кросс-обмена.

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

Когда я смотрю на список тестов, я рассуждаю: «Это очевидно, это очевидно, об этом я не имею ни малейшего представления, это очевидно, здесь – никаких идей, о чем я думал, когда писал это? А! Вспомнил! Я думаю, что мог бы это сделать». Этот последний тест я реализую следующим. С одной стороны, он не кажется мне очевидным, с другой стороны, я уверен в том, что смогу заставить его работать.

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

И нисходящий, и восходящий подходы не представляют реального описания процесса. Во-первых, вертикальная метафора – это упрощенная визуализация процесса изменения программы в течение разработки. Для описания процесса разработки, основанной на тестировании, лучше подходит метафора Развития или Эволюции: внешняя среда влияет на программу, а программа влияет на внешнюю среду. Во-вторых, если мы хотим, чтобы в нашей метафоре присутствовало направление, лучшим описанием будет «от известного к неизвестному». Подразумевается, что мы обладаем некоторыми знаниями и опытом и ожидаем, что в процессе разработки мы будем узнавать нечто новое. Объединим эти две метафоры и получим, что программа эволюционирует от известного к неизвестному.

С какого теста следует начать разработку? Начните с тестирования варианта операции, который не подразумевает выполнения каких-либо осмысленных действий, то есть ничего не делает.

Приступая к реализации операции, вы прежде всего должны ответить на вопрос: «Где она должна располагаться?» Пока вы не ответите на этот вопрос, вы не будете знать, какой код необходимо написать, чтобы протестировать эту операцию. Как уже неоднократно рекомендовалось, не следует решать несколько проблем одновременно. Значит, вы должны выбрать такой тест, который позволит вам искать ответ только на один этот вопрос и на время забыть обо всех остальных вопросах.

Если вы с самого начала приступите к реализации реалистичного теста, вам придется искать ответы на несколько вопросов одновременно:

• Где должна располагаться операция?

• Какие входные данные считать корректными?

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

Если вы начнете с реалистичного теста, вы слишком долгое время будете вынуждены действовать без обратной связи. Красный – зеленый – рефакторинг, красный – зеленый – рефакторинг. На выполнение этого цикла должно уходить всего несколько минут.

Но как сократить время цикла? Для этого вы можете воспользоваться тривиальными входными и выходными данными. Вот простой пример: если функция должна складывать многозначные вещественные числа с точностью до тысячного знака после запятой, вовсе не обязательно начинать ее реализацию с теста, проверяющего результат сложения таких огромных чисел. Вполне можно начать с тривиального теста 3 + 4 = 7. Вот еще один пример. В группе электронных новостей, посвященной экстремальному программированию, один из участников поинтересовался, как написать программу минимизации количества полигонов (многоугольников), составляющих некоторую поверхность. На вход подается набор полигонов, комбинация которых представляет собой некоторый трехмерный объект. На выходе должна получиться комбинация полигонов, которая описывает точно такой же объект (поверхность), но включает в себя минимальное возможное количество полигонов. «Как я могу разработать подобную программу, если для того, чтобы заставить тест сработать, я должен быть как минимум доктором наук?»

Используя шаблон «Начальный тест» (Starter Test), мы получаем ответ:

• Вывод должен быть точно таким же, как ввод. Некоторые комбинации полигонов изначально являются минимальными.

• Ввод должен быть как можно меньшего размера. Например, единственный полигон или даже пустой список полигонов.

Мой начальный тест выглядел следующим образом:

Reducer r = new Reducer(new Polygon());

assertEquals(0, reducer.result(). npoints);

Отлично! Первый тест заработал. Теперь можно перейти к остальным тестам в списке…

К начальному тесту следует применить рассмотренное ранее правило «Тест одного шага» (One Step Test): самый первый тест должен научить вас чему-то новому, кроме того, вы должны обладать возможностью достаточно быстро заставить его работать. Если вы реализуете подобный код уже не в первый раз, вы можете выбрать начальный тест для одной или даже двух операций. Вы должны быть уверены, что сможете быстро заставить тест работать. Если вы приступаете к реализации чего-либо достаточно сложного и делаете это впервые, начните с самого простого теста, который вы только можете представить.

Я часто замечаю, что мой начальный тест работает на достаточно высоком уровне и скорее напоминает тест всего приложения. Например, простой сетевой сервер. Самый первый тест выглядит следующим образом:

StartServer

Socket= new Socket

Message = "hello"

Socket.write(message)

AssertEquals(message, socket.read)

Остальные тесты пишутся только на стороне сервера: «Предположим, что мы получаем строки наподобие этой…»

Как распространить в своей команде использование автоматического тестирования? Для любых объяснений используйте тесты и спрашивайте тесты у тех, кто пытается вам что-либо объяснить.

Если вы единственный член команды, работающий в стиле TDD, вы можете почувствовать себя неуютно и одиноко. Однако вскоре после того, как вы начнете работать в стиле TDD, вы обратите внимание на уменьшение количества проблем, связанных с интеграцией, и снижение количества дефектов, обнаруженных в проверенном коде. Дизайн вашего кода будет проще, и его легче будет объяснять. Может случиться так, что ваши коллеги проявят интерес к тестированию и предварительному тестированию разрабатываемого кода.

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

Но что можно сделать? Лучше всего предлагать вашим коллегам объяснять работу кода в форме тестов: «Подожди-ка, если я правильно понял, объект Foo будет таким, а объект Bar будет таким, значит, в результате получится 76?» Кроме того, вы можете объяснять работу кода в виде тестов: «Вот как это работает. Если объект Foo будет таким, а объект Bar будет таким, в результате получится 76. Однако если объект Foo будет таким, а объект Bar будет таким, в результате получится 67».

Вы можете делать это на более высоком уровне абстракции. Если кто-то пытается объяснить вам работу кода при помощи диаграммы последовательности обмена сообщениями, вы можете предложить ему преобразовать эту диаграмму в более понятную форму. После этого вы пишете тест, содержащий в себе все видимые на диаграмме объекты и сообщения.

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

Предположим, что вы приступаете к разработке программы, основанной на использовании библиотеки Mobile Information Device Profile (MIDP) для языка Java. Вы собираетесь сохранить некоторые данные в объекте RecordStore и затем извлечь их оттуда. Должны ли вы просто написать код в надежде на то, что он заработает? Это один из возможных методов разработки.

Есть альтернативный метод. Обратите внимание на то, что вы собираетесь использовать новый метод нового класса. Вместо того чтобы просто воспользоваться им внутри разрабатываемого вами кода, вы пишете небольшой тест, который позволяет вам убедиться в том, что API работает так, как вы того ожидаете. Таким образом, вы можете написать:

RecordStore store;

public void setUp() {

store = RecordStore.openRecordStore("testing", true);

}

public void tearDown() {

RecordStore.deleteRecordStore("testing");

}

public void testStore() {

int id = store.addRecord(new byte[] {5, 6}, 0, 2);

assertEquals(2, store.getRecordSize(id));

byte[] buffer = new byte[2];

assertEquals(2, store.getRecord(id, buffer, 0));

assertEquals(5, buffer[0]);

assertEquals(6, buffer[1]);

}

Если ваше понимание API совпадает с действительностью, значит, тест сработает с первого раза.

Джим Ньюкирк рассказал мне о проекте, в котором разработка тестов для обучения выполнялась на регулярной основе. Как только от сторонних разработчиков поступала новая версия пакета, немедленно запускались имеющиеся тесты. В случае необходимости в тесты вносились исправления. Если тесты завершались неудачей, не было никакого смысла запускать приложение, так как оно определенно не заработает. Если же все тесты выполнялись успешно, значит, и приложение заработает.

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

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

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

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

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

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

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

Возможно, для того чтобы изолировать дефект, вам потребуется выполнить рефакторинг системы. В этом случае, демонстрируя дефект, система как бы говорит вам: «Ты еще не вполне закончил проектировать меня».

Что делать, если вы почувствовали усталость или зашли в тупик? Прервите работу и отдохните.

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

Иногда самого короткого перерыва достаточно, чтобы недостающая идея возникла в вашей голове. Возможно, вставая из-за компьютера, вы неожиданно нащупаете нужную нить: «Да я же не попробовал этот метод с пересмотренными параметрами!» В любом случае прервитесь. Дайте себе пару минут. Идея никуда не убежит.

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

Дэйв Унгар (Dave Ungar) называет это Методологией душа (Shower Methodology). Если вы знаете, что писать, – пишите. Если вы не знаете, что писать, примите душ и стойте под ним до тех пор, пока не поймете, что нужно писать. Очень многие команды были бы более счастливыми, более продуктивными и пахли бы существенно лучше, если бы воспользовались этим советом.

TDD – это усовершенствование предложенной Унгаром методологии душа. Если вы знаете, что писать, пишите очевидную реализацию. Если вы не знаете, что писать, создайте поддельную реализацию. Если правильный дизайн по-прежнему не ясен, триангулируйте. Если вы по-прежнему не знаете, что писать, можете, наконец, принять душ.

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

Чтобы разорвать этот замкнутый круг, необходимо добавить дополнительный внешний элемент.

• В масштабе нескольких часов держите бутылку с водой рядом с вашей клавиатурой и время от времени прихлебывайте из нее. Благодаря этому естественная физиология будет подсказывать вам, когда и зачем необходимо сделать короткий перерыв в работе.

Рис. 26.1. Усталость негативно влияет на рассудительность, которая негативно влияет на усталость

• В масштабе дня вы должны хорошо отдохнуть после завершения рабочего времени.

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

• В масштабе года вы получаете отпуск, что позволяет вам полностью освежиться. Французы подходят к этому вопросу очень правильно – двух последовательных недель отпуска недостаточно. В течение первой недели вы сбрасываете с себя рабочее напряжение, а в течение второй недели подсознательно готовите себя к работе. Поэтому, чтобы хорошо отдохнуть и эффективно работать в течение всего следующего года, требуется три, а лучше четыре недели отдыха.

Существует обратная сторона данного шаблона. Иногда, если перед вами стоит сложная проблема, требуется, наоборот, поднажать, поднапрячься и потратить дополнительное время и усилия, чтобы решить ее. Однако большинство программистов инфицировано духом саморазрушения: «Я угроблю свое здоровье, отрекусь от своей семьи и даже выпрыгну из окна, лишь бы этот код заработал». Поэтому я не буду давать здесь каких-либо советов. Если вы чувствуете, что у вас развивается болезненное пристрастие к кофе, наверное, вам не стоит делать слишком частых перерывов. В крайнем случае, просто пройдитесь.

Что делать, если вы зашли в тупик? Выкиньте код и начните работу сначала.

Вы заблудились. Вы решили передохнуть. Вымыли руки. Еще раз попытались вспомнить дальнейший путь. И все равно вы заблудились. Код, который выглядел так неплохо всего час назад, теперь выглядит запутанно и непонятно, одним словом, отвратительно. Вы не можете представить себе, как заставить работать следующий тест, а впереди у вас еще 20 тестов, которые необходимо реализовать.

Подобное случалось со мной несколько раз, пока я писал эту книгу. Код получался слишком кривым. «Но я должен закончить книгу. Мои дети хотят есть, а сборщики налогов стучаться в мою дверь.» У меня возникает желание выпрямить код настолько, чтобы можно было продолжать двигаться вперед. Однако на самом деле в большинстве случаев продуктивнее отдохнуть немного и начать все заново. Однажды я был вынужден выкинуть 25 страниц рукописи потому, что она была основана на очевидно глупом программистском решении.

Хорошую историю на эту тему рассказал мне Тим Макиннон (Tim Mackinnon). Однажды он проводил собеседование с потенциальным новым сотрудником. Чтобы оценить уровень его мастерства, он предложил ему программировать в паре в течение часа. К концу этого часа они реализовали несколько новых тестов и провели несколько сеансов рефакторинга. Однако это был конец рабочего дня, они оба чувствовали себя усталыми, поэтому решили полностью убрать из системы результаты своей работы.

Если вы программируете в паре, смена партнера – это хороший повод отказаться от плохого кода и начать решение задачи с начала. Вы пытаетесь объяснить смысл запутанного кода, над которым работали до этого, и вдруг ваш партнер, совершенно не связанный с ошибками, которые вы допустили, берет у вас клавиатуру и говорит: «Я ужасно извиняюсь за мою тупость, но что, если мы попробуем начать по-другому?»

В какой физической обстановке следует использовать TDD? Используйте удобное, комфортное кресло. На всей остальной мебели можно сэкономить.

Вы не сможете хорошо программировать, если ваша спина будет болеть. К сожалению, организации, которые выкладывают по $100 000 в месяц за работу команды программистов, как правило, отказываются тратить $10 000 на покупку хороших кресел.

Я предлагаю использовать дешевые, самые примитивные и ужасные на вид столы для установки компьютеров, но купить самые лучшие кресла, которые я только смогу найти. Дешевых столов можно купить столько, сколько нужно, значит, я получаю в свое распоряжение достаточное количество рабочего места и могу легко его увеличить. При этом я чувствую себя комфортно за компьютером, моя спина не устает.

Если вы программируете в паре, позаботьтесь о том, чтобы вам было удобно. Расчистите пространство на столе, чтобы вам было удобно передавать клавиатуру из рук в руки. Когда я работаю наставником, я люблю выполнять один простой прием: незаметно подходить со спины к программирующей паре и ненавязчиво поправлять клавиатуру так, чтобы она располагалась удобно по отношению к человеку, который с ней работает.

Манфред Лэндж (Manfred Lange) считает, что аккуратное распределение ресурсов необходимо выполнить также в отношении компьютерного аппаратного обеспечения. Рекомендуется использовать дешевые/медленные/старые компьютеры для индивидуальной электронной почты и работы с Интернетом, но зато приобрести самые современные и самые быстрые компьютеры для разработки.