Не удается загрузить DLL при выполнении тестов с MS-Test

Question

В моей программе я использую SevenZipSharp для генерации zip-файлов. SevenZipSharp - это управляемая DLL, которая загружает другую DLL, 7z.dll. Я вручную устанавливаю путь SevenZipSharp к 7z.dll, используя SevenZipCompressor.SetLibraryPath.

Когда я выполняю свою программу в режиме отладки, все это прекрасно работает и генерирует zip-файл настолько хорошо, насколько вам угодно. Однако, когда я выполняю свои модульные тесты с помощью mstest, SevenZipSharp всегда выдает мне следующую ошибку:

"Исключение метода теста: SevenZip.SevenZipLibraryException: не удается загрузить библиотеку 7-zip или внутренняя ошибка COM! Сообщение: не удалось загрузить библиотеку .."

Я подозреваю, что MSTest может делать что-то, что мешает SevenZipSharp загрузить 7z.dll, например, работать в защищенной песочнице (или что-то в этом роде. Я новичок в C # и MSTest ...)

Кто-нибудь имеет представление о том, что может происходить?

Спасибо!

Answer 1

Хотя вопрос представляет собой сомнительный сценарий, общая проблема MSTest, не загружающая требуемые библиотеки DLL, кажется общей, заслуживающей менее пренебрежительного ответа.

1. По умолчанию MSTest копирует сборки, которые, по его мнению, необходимы тестовому контейнеру, в папку Out папки результатов по умолчанию, которая изменяется при каждом запуске.

2. MSTest не всегда автоматически выводит нужные сборки правильно; если нет явной прямой ссылки на сборку, она не будет скопирована. Кроме того, собственные библиотеки DLL обычно не обнаруживаются.

3. Мне неизвестна опция direct для установки пути поиска MSTest. Вы можете определить путь поиска, используя procmon.exe, как предложено выше (это в основном стандартный поиск Windows DLL).

4. Необязательно, путь поиска по умолчанию не включает каталог запуска , и я думаю, что это является причиной путаницы. Когда выполняются тесты, текущим каталогом является каталог результатов теста Out, а не каталог запуска MSTest.

Тем не менее, позволяет управлять поведением поиска MSTest (и поведением копирования) с помощью файла настроек теста . Вы можете легко создавать и редактировать их через Visual Studio (см. Меню «Тест»), а затем указать созданный файл настроек в командной строке MSTest. Вы можете использовать разные файлы настроек для Visual Studio и MSTest.

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

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

Answer 2

Подумайте об использовании Process Monitor (aka procmon.exe) из превосходных инструментов SysInternals для мониторинга вашего тестового жгута (MSTest). Он покажет вам, где исполняемый файл ищет 7z.dll.

Answer 3

Visual Studio 2017 (и, возможно, 2015) предоставляет два новых способа указать, что для ваших тестов требуется собственная dll или другой файл без необходимости файла настроек теста:

1: Добавьте ссылку на dll в ваш тестовый проект и скажите VS скопировать ее в выходной каталог. Щелкните правой кнопкой мыши проект в обозревателе решений и выберите «Добавить»> «Существующий элемент». Найдите файл 7z.dll, щелкните стрелку вниз рядом с кнопкой «Добавить» и выберите «Добавить как ссылку». Затем выберите новый элемент 7z.dll в обозревателе решений, нажмите alt-Enter, чтобы вызвать свойства, и установите для параметра «Копировать в выходной каталог» значение «Копировать, если новее» (или «Копировать всегда»).

2: прикрепите DeploymentItemAttribute к вашему тестовому классу. Конструктор этого атрибута принимает единственный строковый аргумент, который является путем к файлу, который вы хотите сделать доступным для тестов в классе. Относится к выходному каталогу тестового проекта.

Answer 4

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

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

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

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

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