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

Мораль проста: тестовый код не менее важен, чем код продукта. Не считайте его «кодом второго сорта». К написанию тестового кода следует относиться вдумчиво, внимательно и ответственно. Тестовый код должен быть таким же чистым, как и код продукта.

Тесты как средство обеспечения изменений

Если не поддерживать чистоту своих тестов, то вы их лишитесь. А без тестов утрачивается все то, что обеспечивает гибкость кода продукта. Да, вы не ошиблись. Именно модульные тесты обеспечивают гибкость, удобство сопровождения и возможность повторного использования нашего кода. Это объясняется просто: если у вас есть тесты, вы не боитесь вносить изменения в код! Без тестов любое изменение становится потенциальной ошибкой. Какой бы гибкой ни была ваша архитектура, каким бы качественным ни было логическое деление вашей архитектуры, без тестов вы будете сопротивляться изменениям из опасений, что они приведут к появлению скрытых ошибок.

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

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

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

Чистые тесты

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

В листинге 9.1 приведен фрагмент кода из проекта FitNesse. Эти три теста трудны для понимания; несомненно, их можно усовершенствовать. Прежде всего, повторные вызовы addPage и assertSubString содержат огромное количество повторяющегося кода [G5]. Что еще важнее, код просто забит второстепенными подробностями, снижающими выразительность теста.

Листинг 9.1. SerializedPageResponderTest.java

public void testGetPageHieratchyAsXml() throws Exception

{

  crawler.addPage(root, PathParser.parse("PageOne"));

  crawler.addPage(root, PathParser.parse("PageOne.ChildOne"));

  crawler.addPage(root, PathParser.parse("PageTwo"));

  request.setResource("root");

  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);

}

public void testGetPageHieratchyAsXmlDoesntContainSymbolicLinks()

  throws Exception

{

  WikiPage pageOne = crawler.addPage(root, PathParser.parse("PageOne"));

  crawler.addPage(root, PathParser.parse("PageOne.ChildOne"));

  crawler.addPage(root, PathParser.parse("PageTwo"));

  PageData data = pageOne.getData();

  WikiPageProperties properties = data.getProperties();

  WikiPageProperty symLinks = properties.set(SymbolicPage.PROPERTY_NAME);

  symLinks.set("SymPage", "PageTwo");

  pageOne.commit(data);

  request.setResource("root");