NUnit으로 app.config 파일 단위 테스트

NUnit으로 app.config 파일 단위 테스트

---

app.config 파일의 값에 의존하는 애플리케이션을 단위 테스트 할 때? 이러한 값이 올바르게 읽혀 졌는지 그리고 프로그램이 구성 파일에 입력 된 잘못된 값에 어떻게 반응하는지 어떻게 테스트합니까?

NUnit 앱의 구성 파일을 수정해야한다는 것은 말도 안되지만 테스트하려는 app.config의 값을 읽을 수 없습니다.

편집 : 아마도 분명히해야한다고 생각합니다. ConfigurationManager가 값을 읽지 못하는 것에 대해 걱정하지 않지만 프로그램이 읽은 값에 어떻게 반응하는지 테스트하는 데 관심이 있습니다.

---

나는 보통 기능이 거의없는 자신의 파사드 클래스에서 구성 파일을 읽는 것과 같은 외부 종속성을 격리합니다. 테스트에서 실제 구성 파일 대신 구현하고 사용하는이 클래스의 모의 버전을 만들 수 있습니다. 직접 목업을 만들거나 moq 또는 rhino 목업과 같은 프레임 워크를 사용할 수 있습니다.

이렇게하면 먼저 xml 구성 파일을 작성하는 복잡한 테스트를 작성하지 않고도 다양한 구성 값으로 코드를 쉽게 시험해볼 수 있습니다. 구성을 읽는 코드는 일반적으로 매우 간단하여 테스트가 거의 필요하지 않습니다.

---

테스트 설정에서 런타임에 구성 섹션을 수정할 수 있습니다. 예 :

// setup
System.Configuration.Configuration config = 
     ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.Sections.Add("sectionname", new ConfigSectionType());
ConfigSectionType section = (ConfigSectionType)config.GetSection("sectionname");
section.SomeProperty = "value_you_want_to_test_with";
config.Save(ConfigurationSaveMode.Modified);
ConfigurationManager.RefreshSection("sectionname");

// carry out test ...

물론이 작업을보다 우아하게 수행하기 위해 고유 한 도우미 메서드를 설정할 수 있습니다.

---

ConfigurationManager.AppSettings의 set 메서드를 호출하여 특정 단위 테스트에 필요한 값을 설정할 수 있습니다.

[SetUp]
public void SetUp()
{
  ConfigurationManager.AppSettings.Set("SettingKey" , "SettingValue");
  // rest of unit test code follows
}

단위 테스트가 실행되면이 값을 사용하여 코드를 실행합니다.

---

클래스 를 사용하여 app.config파일을 읽고 쓸 수 있습니다.ConfigurationManager

---

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/the-simplest-form-of-configurable-dependency-injection/

---

보다 우아한 솔루션은 구성 설정 자체에 일반 오래된 종속성 주입을 사용하는 것입니다. IMHO 이것은 구성 읽기 클래스 / 래퍼 등을 모의하는 것보다 깨끗합니다.

For example, say a class "Weather" requires a "ServiceUrl" in order to function (e.g. say it calls a web service to get the weather). Rather than having some line of code that actively goes to a configuration file to get that setting (whether that code be in the Weather class or a separate configuration reader that could be mocked as per some of the other responses), the Weather class can allow the setting to be injected, either via a parameter to the constructor, or possibly via a property setter. That way, the unit tests are extremely simple and direct, and don't even require mocking.

The value of the setting can then be injected using an Inversion of Control (or Dependency Injection) container, so the consumers of the Weather class don't need to explicitly supply the value from somewhere, as it's handled by the container.

---

That worked for me:

 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);
  }

---

You can always wrap the reading-in bit in an interface, and have a specific implementation read from the config file. You would then write tests using Mock Objects to see how the program handled bad values. Personally, I wouldn't test this specific implementation, as this is .NET Framework code (and I'm assuming - hopefully - the MS has already tested it).

---

System.Configuration.Abstractions is a thing of beauty when it comes to testing this kind of stuff.

Here is the GitHub project site with some good examples: enter link description here

Here is the NuGet site: https://www.nuget.org/packages/System.Configuration.Abstractions/

I use this in almost all of my .NET projects.

---

Actually, thinking on it further, I suppose what I should do is create a ConfigFileReader class for use in my project and then fake it out in the unit test harness?

Is that the usual thing to do?

---

The simplest option is to wrap the methods that read configuration such that you can substitute in values during testing. Create an interface that you use for reading config and have an implementation of that interface get passed in as a constructor parameter or set on the object as a property (as you would using dependency injection/inversion of control). In the production environment, pass in an implementation that really reads from configuration; in the test environment, pass in a test implementation that returns a known value.

If you don't have the option of refactoring the code for testability yet still need to test it, Typemock Isolator provides the ability to actually mock the .NET framework configuration classes so you can just say "next time I ask for such-and-such appSettings value, return this known value."

---

I had the same issue,

you can use Nunit-console.exe c:\path1\testdll1.dll c:\path2\testdll2.dll

this works fine even though if both dlls point to different app.configs ex testdll1.dll.config and testdll2.dll.config

if you want to use Nunit project config and wrap these two dlls then there is no way you can have two configs

you have to have project1.config if your Nunit project is project1.nunit in the same location as Project1.nunit sits.

hope this helps

---

Well, I just had the same problem... I wanted to test a BL project that is referenced from a web site . but i wanted to test the BL only. So in the pre-build event of the test project I copy the app.Config files into the bin\debug folder and reference them from the app.config ...

참고URL : https://stackoverflow.com/questions/168931/unit-testing-the-app-config-file-with-nunit