в множество при обращении к методам и в выражении assert использовать операцию сравнения множеств.

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

Тестирование обработки ошибок (Crush Test Dummy)

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

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

Предположим, что мы хотим проверить, что происходит с нашим приложением в случае, если на диске не остается свободного места. Неужели для этого необходимо вручную создавать огромное количество файлов? Есть альтернатива. Мы можем сымитировать заполнение диска, фактически использовав шаблон «Подделка» (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) {

}

}

Сломанный тест (Broken Test)

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

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

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

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

Чистый выпускаемый код (Clean Check-in)

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

Я противоречу сам себе? Да.

Бубба Уитман (Bubba Whitman), брат Уолта – портового грузчика

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

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

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

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

28. Шаблоны зеленой полосы

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

Подделка (Fake It)

Если у вас есть

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

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

Отметить Добавить цитату