Модульные тесты и длинные строки настройки: стиль / лучшие практики

Question

Меня интересует мнение, практика и рекомендуемые лучшие практики использования длинных строк настройки в модульных тестах.

Предпочитаете ли вы объявлять тесты как встроенные, близкие к вашему тесту или выводить их в файл где-нибудь?

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

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

Например, я пишу быстрый парсер для удаления неиспользуемых объявлений css из файлов. Я хочу проверить, что с учетом конкретной входной строки, правильный текст удаляется. Мой тест стал очень шумным со всей конкатенацией строк.

public void removesStyleFromText() 
{
    StyleCleaner styleCleaner = new StyleCleaner();
    String source = ".presentInFileOne {\r\n" + 
            "}\r\n" + 
            "\r\n" + 
            ".presentInFileTwo {\r\n" + 
            "   bottom-corners-rounded : false;\r\n" + 
            "}\r\n" + 
            ".notUsed {\r\n" + 
            "}\r\n" + 
            "";

    String actual = styleCleaner.removeDeclaration(source , "notUsed");

    String expected = ".presentInFileOne {\r\n" + 
    "}\r\n" + 
    "\r\n" + 
    ".presentInFileTwo {\r\n" + 
    "   bottom-corners-rounded : false;\r\n" + 
    "}\r\n";

    assertEquals(expected , actual);
}

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

Мысли

Answer 1

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

Если у вас есть много одинаковых тестов, которые отличаются только тем, в какую строку входит и какая строка идет, история немного отличается, однако, вы можете захотеть взглянуть на решения для тестирования на основе таблиц. В .Net у вас есть mbunit. Он позволяет вам запускать один и тот же тест с разными ожидаемыми значениями ввода / вывода, или вы можете посмотреть на такие инструменты, как Fitnesse, которые позволяют вам определять таблицы данных, с которыми вы хотите провести тестирование.

Answer 2

Определенно код, гораздо проще сразу сказать, что вы тестируете, и намного проще выполнить рефакторинг, если вы хотите использовать его повторно. Мне нравится сохранять его СУХИМЫМ, поэтому я обычно склоняюсь к его переносу в конструкторы или конкретные классы (в зависимости от того, что я делаю), что дает мне конфигурацию по умолчанию, которую я могу настроить для конкретного теста.

Answer 3

Есть способ заставить многострочные литералы Strings работать в Java . Вероятно, производительность - это не то, что вы хотели бы видеть в производстве, но достаточно для тестов.

Мое правило: если строка небольшая (<10 строк), я сохраняю их встроенными, но таким образом, что я всегда могу вырезать все между "" и просто вставить новую версию (это означает, что я конвертирую строки в моем assertEquals () при необходимости). </p>

Если строковый литерал длиннее, сложнее или когда у меня есть хороший редактор (с подсветкой синтаксиса и т. Д.), Я хотел бы хранить их в папке с тестовыми данными с именем теста в качестве имени файла. Затем вы можете использовать служебную функцию в вашем тесте JUnit, которая использует getName () для загрузки строки, и вы без всякой магии узнаете, какой файл принадлежит какому тесту.

Если у вас их много, я использую имя класса теста (class.getSimpleName ()) в качестве имени папки, чтобы сохранить контроль над ними.

Answer 4

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

source = """
.presentInFileOne {
}

.presentInFileTwo {
       bottom-corners-rounded : false;
}
.notUsed {
}
"""

expected = """
.presentInFileOne {
}

.presentInFileTwo {
       bottom-corners-rounded : false;
}
"""

assert removeDeclaration(source, "notUsed") == expected

Такие языковые конструкции сделают ваши тесты более читабельными, чем что-либо еще.

Answer 5

Я бы позволил это так - поскольку он важен для этого теста и строго проверен, если вы полагаетесь в своем тесте на что-то «внешнее», это не строгий юнит-тест.

Answer 6

Я бы выделил строки и написал несколько комментариев о том, что вы тестируете. Преимущество комментариев в том, что они намного более читабельны, чем строковые конструкции.