Модульное тестирование с длинными входами

Question

[TestMethod]
public void SomeTestMethod()
{
    string input = "some looooong input...";

    var proc = new Processor()
    string result = proc.DoSomething(input);

    Assert.Equals("good", result);
}

Если я пишу модульный тест и у меня очень длинный ввод (например, транзакции EDI), должен ли я просто вставить его в свой метод теста в виде длинной строки?

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

Есть ли лучшие практики, связанные с этим? Должен ли я просто продолжать вставлять эти длинные строки в мои методы тестирования?

Answer 1

Я всегда помещаю длинные тестовые строки в ресурсы и поддерживаю согласованное именование между тестами и их ресурсами, чтобы облегчить сопоставление.Я использую одно и то же имя для ресурса и теста.Когда мне нужно несколько ресурсов для теста, я добавляю суффикс 1, 2, 3 и т. Д.

Answer 2

Вы можете использовать другой строковый конструктор для создания очень длинной строки повторяющихся символов, например:

string input = new string('x', 1024 * 1024 / 2);

Такой подход дает гораздо более элегантный способ создания длинных строк без необходимости вставлять длинные строки в ваши тесты.

Answer 3

Я тестировал некоторые регулярные выражения против файла. Я скопировал и вставил содержимое файла в тестовый класс как обычное свойство, но я использовал теги #region, чтобы скрыть его. Мне не нужно видеть 200 строк текста каждый раз, когда я открываю этот тестовый класс. Это также один из немногих случаев, когда я нахожу тег #region полезным.

Answer 4

Не зная, как я понимаю, код Processor, Processor должен иметь простые, быстрые модульные тесты, охватывающие его внутреннюю работу, тогда как такие тесты, как SomeTestMethod, должны рассматриваться как Интеграционные тесты .

Таким образом, я бы сохранял все свои тестовые данные в файле XML и загружал их в тест, выполняя один и тот же тест для каждого ввода (если вы хотите проверить серьезные объемы данных - вы можетеиспользовать базу данных).Нет необходимости писать отдельные тесты для каждого входа.

Очень чистый и элегантный подход к тому, как это делается в MSTest, описан здесь .

Answer 5

Это просто «самоуверенный» ответ, так как я никогда не видел наилучшей практики в этом отношении;

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

Мы обнаружили, что обработка внешних файлов сама по себе подвержена ошибкам.

Answer 6

Если это что-то быстрое, что меня не волнует, я добавляю это в код.Так как я, скорее всего, тестирую концепцию.

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