Элемент configSource решение, данное Марком Лоуренсом, - это то, что я искал, и оно прекрасно работает. Однако проблема при реализации этого решения состоит в том, чтобы загрузить конфигурацию сборки при запуске тестов из явного проекта 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 (), которая не принимает path, мы загружаем конфигурацию из рабочего каталога хост-приложения, который меняется в зависимости от того, как вы запускаете тесты NUnit. Кроме того, блок try / finally гарантирует, что ваша конфигурация сборки не будет мешать другим тестам, которые могут требовать или не требовать такой конфигурации.
Наконец, для использования в модульном тесте:
[Test]
void VerifyFunctionality
{
WithConfigurationFile(delegate
{
// implement unit test and assertions here
});
}
Надеюсь, это поможет другим, кто, возможно, сталкивался с подобными проблемами!
person
Steve Guidi
schedule
19.09.2009
