Поблочное тестирование app.config файл с NUnit

У меня были похожие проблемы с web.config .... Я нашел интересное решение. Вы можете инкапсулировать функцию чтения конфигурации, например, что-то вроде этого:

public class MyClass {

public static Func<string, string> 
     GetConfigValue = s => ConfigurationManager.AppSettings[s];

//...

}

И затем обычно используйте

string connectionString = MyClass.GetConfigValue("myConfigValue");

, но в модульном тесте инициализируйте "переопределение" функции следующим образом:

MyClass.GetConfigValue = s =>  s == "myConfigValue" ? "Hi", "string.Empty";

Подробнее об этом:

http: // rogeralsing .com / 2009/05/07 / простейшая-форма-конфигурируемой-зависимости-инъекции /

Более элегантное решение - использовать простую инъекцию старых зависимостей в сами параметры конфигурации. ИМХО, это чище, чем имитировать класс / оболочку чтения конфигурации и т. Д.

Например, скажем, класс «Погода» требует «ServiceUrl» для работы (например, скажем, он вызывает веб-сервис, чтобы узнать погоду) . Вместо того, чтобы иметь некоторую строку кода, которая активно переходит в файл конфигурации для получения этой настройки (будь то код в классе Weather или в отдельном считывающем устройстве конфигурации, которое можно было бы имитировать в соответствии с некоторыми другими ответами), класс Weather может разрешить параметр, который должен быть введен, либо через параметр конструктора, либо, возможно, через установщик свойств. Таким образом, модульные тесты становятся чрезвычайно простыми и прямыми и даже не требуют имитации.

У меня сработало:

 public static void BasicSetup()
  {
     ConnectionStringSettings connectionStringSettings = 
          new ConnectionStringSettings();
     connectionStringSettings.Name = "testmasterconnection";
     connectionStringSettings.ConnectionString = 
          "server=localhost;user=some;database=some;port=3306;";
     ConfigurationManager.ConnectionStrings.Clear();
     ConfigurationManager.ConnectionStrings.Add(connectionStringSettings);
  }