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

def testTemplateMethod(self):

test = WasRun("testMethod")

result = TestResult()

test.run(result)

assert("setUp testMethod tearDown " == test.log)

Реализация тоже очень проста:

WasRun

def setUp(self):

self.log = "setUp "

def testMethod(self):

self.log = self.log + "testMethod "

def tearDown(self):

self.log = self.log + "tearDown "

Шаблон «Строка-журнал» (Log String) особенно полезен в случае, когда вы реализуете шаблон «Наблюдатель» (Observer) и желаете протестировать порядок поступления оповещений. Если вас прежде всего интересует, какие именно оповещения генерируются, однако порядок их поступления для вас не важен, вы можете создать множество строк, добавлять строки в множество при обращении к методам и в выражении assert использовать операцию сравнения множеств.

Шаблон «Строка-журнал» (Log String) хорошо сочетается с шаблоном «Самошунтирование» (Self Shunt). Объект-тест реализует методы шунтируемого интерфейса так, что каждый из них добавляет запись в строку-журнал, затем проверяется корректность этих записей.

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

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

Предположим, что мы хотим проверить, что происходит с нашим приложением в случае, если на диске не остается свободного места. Неужели для этого необходимо вручную создавать огромное количество файлов? Есть альтернатива. Мы можем сымитировать заполнение диска, фактически использовав шаблон «Подделка» (Fake It).

Вот наш тест для класса File:

private class FullFile extends File {

public FullFile(String path) {

super(path);

}

public boolean createNewFile() throws IOException {

throw new IOException();

}

}

Теперь мы можем написать тест ожидаемого исключения:

public void testFileSystemError() {

File f = new FullFile("foo");

try {

saveAs(f);

fail();

} catch (IOException e) {

}

}

Тест кода обработки ошибки напоминает шаблон «Поддельный объект» (Mock Object), однако в данном случае нам не надо подделывать весь объект. Для реализации этой методики удобно использовать анонимные внутренние классы языка Java. При этом вы можете переопределить только один необходимый вам метод. Сделать это можно прямо внутри теста, благодаря чему код теста станет более понятным:

public void testFileSystemError() {

File f = new File("foo") {

public boolean createNewFile() throws IOException {

throw new IOException();

}

};

try {

saveAs(f);

fail();

} catch (IOException e) {

}

}

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

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

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

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

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