Описание: Перед тем как начать писать тесты, составьте список всех тестов, которые вы хотели бы реализовать. Однако это не значит написать их в прямом смысле, а всего лишь внести их в список на бумажке. Если вы напишите пачку тестов за раз - вы нарушите принцип Red-Green-Refactor.

Мотивация

Первая часть такого подхода используется для решения проблем программирования из разряда “никогда не делайте шаг вперед, если не знаете куда ступаете”.

Одна из стратегий следовать тому, что ты хочешь реализовать — это держать все в голове. Кент Бек использовал данный подход в течение нескольких лет и заметил цепочку обратной связи. Чем больше опыта он получал, тем больше он знал что нужно еще будет сделать. Чем больше вещей он знал что нужно еще сделать, тем меньше внимания было к тому, что было уже сделано. Чем меньше внимания было к тому, что было уже сделано, тем меньше было выполнено целей. Чем меньше было выполнено целей, тем больше их нужно было выполнить.

У Кент Бека появилась привычка записывать все, что он желает сделать в течении следующих двух часов, на листке около своего компьютера. У него был похожий список, но только с еженедельным и ежемесячным скоупом, прикрепленный на стене. Как только в этом списке было все записано, он знал, что ничего не забудет. Как только появлялся новый пункт для списка, Кент Бек быстро и сознательно решал, к какому списку принадлежит этот пункт — ”сейчас” или “на попозже”, либо вообще этот пункт становился лишним и не попадал в список.

Обсуждение

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

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

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

Во вторых, если у вас десять сломанных тестов, то вы будете далеки от “green bar”. Если вы хотите быстро добраться до “green bar”, то вам придется выкинуть все эти десять тестов. Если вы хотите, чтобы эти тесты работали, то вы еще долго будете наблюдать за “red bar”.

У горных туристов, альпинистов и скалолазов есть правило “трёх точек опоры”. Смысл его очень прост — при перемещении по опасному склону у тебя в каждый момент времени должно быть три точки опоры. Нога и две руки. Или рука и две ноги. Если ты опирался всего на две точки, и одна из них подвела тебя — семь к одному, что на оставшейся единственной опоре тебе не удержаться. В чистой форме TDD, в которой вы не превышаете одного изменения от “green bar” — это как “правило трех”.

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