Решение configSource element , данное MarkLawrence , - это то, что я искал, и прекрасно работает. Однако задача реализации этого решения состоит в том, чтобы загрузить конфигурацию сборки при выполнении тестов как из явного проекта NUnit (как в my case ), так и при выполнении модульных тестов для сборки в отдельности (нет явный проект). Для этого потребовались следующие изменения в моем макете файла.
+ TestFolder
testProject.nunit
testProject.config
+ AssemblyAFolder
assemblyA.dll
assemblyA.dll.config
assemblyA.dll.configfragment
+ AssemblyBFolder
assemblyB.dll
assemblyB.dll.config
assemblyB.dll.configfragment
Файлы configfragment создаются, чтобы содержать конфигурацию сборки, которая была когда-то в соответствующих файлах config. После этого файлы config модифицируются и содержат только элемент configSource с относительным путем к соответствующему файлу configfragment. Обратите внимание, что единственный раз, когда этот подход не работает, это когда оба элемента assemblyA.dll и assemblyB.dll требуют одного и того же раздела конфигурации, поскольку при создании testproject.config.
может возникнуть конфликт.
После экспериментов с этим подходом я решил положиться на создание конфигурации сборки во время выполнения и удалить все статические файлы конфигурации вместе. Вот некоторый код, который демонстрирует, как сгенерировать конфигурацию и сделать ее доступной независимо от того, как загружается тестируемая сборка.
void WithConfigurationFile(Action method)
{
// Create the assembly configuration.
string settingsSection = "myConfigSectionName";
Configuration config =
ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.Sections.Add(
settingsSection,
new ConfigSectionType(/*config element values*/);
config.Save();
try
{
// Invoke the method with the new configuration.
ConfigurationManager.RefreshSection(settingsSection);
method();
}
finally
{
// Revert the assembly configuration.
File.Delete(config.FilePath);
ConfigurationManager.RefreshSection(settingsSection);
}
}
Используя перегрузку ConfigurationManager.OpenExeConfiguration () , которая не принимает путь, мы загружаем конфигурацию из рабочего каталога хост-приложения, которая изменяется в зависимости от того, как вы выполняете свои тесты NUnit. Кроме того, блок try / finally гарантирует, что конфигурация вашей сборки не будет мешать другим тестам, которые могут требовать или не требовать такой конфигурации.
Наконец, для использования в модульном тесте:
[Test]
void VerifyFunctionality
{
WithConfigurationFile(delegate
{
// implement unit test and assertions here
});
}
Надеюсь, это поможет другим, кто мог столкнуться с подобными проблемами!