Ищите рекомендуемый подход к проектированию модульных тестов, когда мне нужно обрабатывать сложные и большие файлы XML

Question

Я использую проекты модульного тестирования Visual Studio 2017.

У меня есть приложение, которое читает сложные файлы XML и выполняет некоторую обработку на основе запросов XPATH в своих данных. Мне нужно построить серию модульных тестов для моего приложения. Ниже мне на ум приходят два варианта:

Опция # 1 : Включить несколько выбранных файлов XML в рамках проекта модульного тестирования.

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

Опция # 2 : создание фиктивных классов, предоставляющих конкретные сценарии данных XML

Мне нужно создать несколько фиктивных классов, которые предоставляют конкретные сценарии данных XML. Приложение необходимо обновить таким образом, чтобы оно получало данные через классы в контейнере IoC.

Для меня вариант № 1 довольно прост, но я хотел бы получить больше информации о варианте № 2

Вопрос : Вышеуказанные два варианта согласованы с лучшими практиками проектирования модульных тестов? Каков наиболее оптимальный дизайн модульного теста для моего senatio?

Answer 1

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

Мне кажется, что вариант # 1, который, вероятно, является самым быстрым для реализации, отрицательно влияет на выполнение теста (доступ к файлу занимает некоторое время), делает выполнение теста зависимым от среды (разрешения для файла, какой каталог ?, кодировка имени файла, ...), может привести к недетерминированному поведению (файл заблокирован из-за запуска параллельного процесса тестирования) и т. д.

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