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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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