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

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

Самая первая версия xUnit для Smalltalk (под названием SUnit) обладала очень простыми выражениями assert. Если одно из выражений терпело неудачу, автоматически открывалось окно отладчика, вы исправляли код и продолжали работу. Среда разработки Java не настолько совершенна, к тому же построение приложений на Java часто выполняется в пакетном режиме, поэтому имеет смысл добавлять в выражение assert() дополнительную информацию о проверяемом условии. Чтобы в случае неудачи выражения assert() можно было вывести на экран дополнительную информацию.

В JUnit это реализуется при помощи необязательного первого параметра[19]. Например, если вы напишете assertTrue(«Должно быть True», false) и тест не сработает, то вы увидите на экране приблизительно следующее сообщение: Assertion failed: Должно быть True. Обычно подобного сообщения достаточно, чтобы направить вас напрямую к источнику ошибки в коде. В некоторых группах разработчиков действует жесткое правило, что все выражения assert() должны снабжаться подобными информационными сообщениями. Попробуйте оба варианта и самостоятельно определите, окупаются ли для вас затраты, связанные с информационными сообщениями.

Фикстура[20] (Fixture)

Как создаются общие объекты, которые используются в нескольких тестах? Конвертируйте локальные переменные из тестов в переменные-члены класса TestCase. Переопределите метод setUp() и инициализируйте в нем эти переменные (то есть выполните создание всех необходимых объектов).

Если мы привыкли удалять дублирование из функционального (тестируемого) кода, должны ли мы удалять его из тестирующего кода? Может быть.

Существует проблема: зачастую вам приходится писать больше кода для того, чтобы установить объекты, используемые тестируемым методом, в интересующее вас состояние. Код, инициализирующий объекты, часто оказывается одинаковым для нескольких тестов. Такие объекты называются фикстурой теста (используется также английский термин scaffolding – строительные леса, подмостки). Дублирование подобного кода – это плохо. Вот две основные причины:

• написание подобного кода требует дополнительного времени, даже если мы просто копируем блоки текста через буфер обмена. Но наша задача – добиться того, чтобы написание тестов занимало как можно меньше времени;

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

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

Среда xUnit поддерживает оба стиля написания тестов. Если вы думаете, что читателям будет сложно вспомнить объекты фикстуры, вы можете разместить код создания фикстуры непосредственно в теле теста. Однако вы также можете переместить этот код в метод с названием setUp(). В этом методе вы можете создать все объекты, которые будут использоваться в тестовых методах.

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

EmptyRectangleTest

public void testEmpty() {

Rectangle empty = new Rectangle(0,0,0,0);

assertTrue(empty.isEmpty());

}

public void testWidth() {

Rectangle empty = new Rectangle(0,0,0,0);

assertEquals(0.0, empty.getWidth(), 0.0);

}

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

EmptyRectangleTest

private Rectangle empty;

public void setUp() {

empty = new Rectangle(0,0,0,0);

}

public void testEmpty() {

assertTrue(empty.isEmpty());

}

public void testWidth() {

assertEquals(0.0, empty.getWidth(), 0.0);

}