Чистый код. Создание, анализ и рефакторинг

  request.addInput("type", "pages");

  Responder responder = new SerializedPageResponder();

  SimpleResponse response =

      (SimpleResponse) responder.makeResponse(

         new FitNesseContext(root), request);

  String xml = response.getContent();

  assertEquals("text/xml", response.getContentType());

  assertSubString("PageOne", xml);

  assertSubString("PageTwo", xml);

  assertSubString("ChildOne", xml);

  assertNotSubString("SymPage", xml);

}

public void testGetDataAsHtml() throws Exception

{

  crawler.addPage(root, PathParser.parse("TestPageOne"), "test page");

  request.setResource("TestPageOne");

  request.addInput("type", "data");

  Responder responder = new SerializedPageResponder();

  SimpleResponse response =

       (SimpleResponse) responder.makeResponse(

          new FitNesseContext(root), request);

  String xml = response.getContent();

  assertEquals("text/xml", response.getContentType());

  assertSubString("test page", xml);

  assertSubString("

}

Например, присмотритесь к вызовам PathParser, преобразующим строки в экземпляры PagePath, используемые обходчиками (crawlers). Это преобразование абсолютно несущественно для целей тестирования и только затемняет намерения автора. Второстепенные подробности, окружающие создание ответчика, а также сбор и преобразование ответа тоже представляют собой обычный шум. Также обратите внимание на неуклюжий способ построения URL-адреса запроса из ресурса и аргумента. (Я участвовал в написании этого кода, поэтому считаю, что вправе критиковать его.)

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

Теперь рассмотрим усовершенствованные тесты в листинге 9.2. Они делают абсолютно то же самое, но код был переработан в более ясную и выразительную форму.

Листинг 9.2. SerializedPageResponderTest.java (переработанная версия)

public void testGetPageHierarchyAsXml() throws Exception {

  makePages("PageOne", "PageOne.ChildOne", "PageTwo");

  submitRequest("root", "type:pages");

  assertResponseIsXML();

  assertResponseContains(

    "PageOne", "PageTwo", "ChildOne"

  );

}

public void testSymbolicLinksAreNotInXmlPageHierarchy() throws Exception {

  WikiPage page = makePage("PageOne");

  makePages("PageOne.ChildOne", "PageTwo");

  addLinkTo(page, "PageTwo", "SymPage");

  submitRequest("root", "type:pages");

  assertResponseIsXML();

  assertResponseContains(

    "PageOne", "PageTwo", "ChildOne"

  );

  assertResponseDoesNotContain("SymPage");

}

public void testGetDataAsXml() throws Exception {

  makePageWithContent("TestPageOne", "test page");

  submitRequest("TestPageOne", "type:data");

  assertResponseIsXML();

  assertResponseContains("test page", "

}

В структуре тестов очевидно воплощен паттерн ПОСТРОЕНИЕ-ОПЕРАЦИИ-ПРОВЕРКА[29]. Каждый тест четко делится на три части. Первая часть строит тестовые данные, вторая часть выполняет операции с тестовыми данными, а третья часть проверяет, что операция привела к ожидаемым результатам.

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

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

Предметно-ориентированный язык тестирования