Использование файлов тестов / ресурсов для сравнения результатов модульного теста = запах кода? - PullRequest
0 голосов
/ 18 марта 2019

Запах кода - использовать сгенерированный файл, например электронную таблицу или файл XML, в качестве источника для сравнения в модульных тестах?

Скажем, что нам пришлось написать много классов, которые создают различные XML-файлы для последующей обработки. В модульных тестах было бы большое количество повторяющихся утверждений, что foo.getExpectedValue() = expectedValue. Вместо этого разработчик решает использовать код, который должен тестировать, для генерации XML, а затем скопировать его в test / resources для всех будущих тестов, загружаемых в память как объект, и выполнять свои утверждения против. Это запах кода?

Ответы [ 3 ]

0 голосов
/ 21 марта 2019

В том, что вы описываете, есть две практики, которые классифицируются как тестовые запахи.

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

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

Во-вторых, использование полных XML-файлов для сравнения (сгенерировано или нет) является еще одним небольшим тестом. Причина в том, что эти тесты не очень сфокусированы. Любые изменения в генерации XML приведут к провалу теста. Это может показаться хорошей вещью, но это относится даже ко всем предполагаемым изменениям, например, к изменениям отступа. Таким образом, у вас есть только тест, который говорит вам «что-то изменилось», но не «что-то не получилось».

Чтобы иметь тесты, которые сообщают вам «что-то не удалось», вам нужны более конкретные тесты. Например, тесты, которые смотрят только на определенную часть сгенерированного XML. Некоторые тесты будут смотреть на структуру XML, другие - на содержание данных. Вы можете даже иметь тесты для проверки отступа. Но как? Например, вы можете использовать регулярные выражения, чтобы увидеть, выглядит ли какая-то интересная часть сгенерированной строки XML так, как вы ожидали.

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

0 голосов
/ 21 марта 2019

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

0 голосов
/ 19 марта 2019

Да, я бы этого не делал. Это нарушает принципы хорошего теста. В основном, хороший тестовый тест должен быть;

  • Независимо - не следует полагаться на другие тесты. Если последующим тестам придется ждать файл, сгенерированный первым тестом, тесты не являются независимыми.
  • Повторяется - в этих тестах возникает нестабильность из-за зависимости файла / памяти. Следовательно, они не могут быть повторяемыми последовательно.

Возможно, вы могли бы сделать шаг назад и посмотреть, нужно ли вам выполнять модульное тестирование каждого сгенерированного XML. Если бы при создании этих файлов использовался один и тот же путь выполнения кода (без логической разницы), я бы не писал модульный тест для каждого случая. Если генерация XML связана с бизнес-операциями, я бы подумал о приемочных тестах.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...