Jednostka testująca aplikację.plik konfiguracyjny z NUnit

Możesz zmodyfikować sekcję konfiguracji w czasie wykonywania w Ustawieniach testowych. Np.:

// 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 ...

Możesz oczywiście skonfigurować własne metody pomocnicze, aby zrobić to bardziej elegancko.

Można wywołać metodę set ConfigurationManager.AppSettings, aby ustawić wartości wymagane dla tego konkretnego testu jednostkowego.

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

Gdy test jednostkowy zostanie uruchomiony, to użyje tych wartości do uruchomienia kodu

Możesz zarówno odczytywać, jak i zapisywać do pliku app.config za pomocą klasy ConfigurationManager

Miałem podobne problemy z Internetem.config.... Znalazłem ciekawe rozwiązanie. Możesz enkapsulować funkcję odczytu konfiguracji, np. coś takiego:

public class MyClass {

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

//...

}

A następnie normalnie używać

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

Ale w teście jednostkowym inicjalizuj" override " funkcję tak:

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

Więcej na ten temat:

Http://rogeralsing.com/2009/05/07/the-simplest-form-of-configurable-dependency-injection/

Bardziej eleganckim rozwiązaniem jest użycie zwykłego starego wtrysku zależności od samych ustawień konfiguracyjnych. IMHO to jest czystsze niż trzeba wyśmiewać konfigurację odczytu klasy / wrappera itp.

Na przykład, powiedzmy, że Klasa "Weather" wymaga "ServiceUrl" do działania (np. Zamiast mieć jakąś linijkę kodu, która aktywnie przechodzi do pliku konfiguracyjnego, aby uzyskać to ustawienie (niezależnie od tego, czy kod jest w klasie Weather, czy oddzielny czytnik konfiguracji, który może być wyśmiewany, jak na niektóre z innych odpowiedzi), Klasa Weather może pozwolić na wstrzyknięcie ustawienia, albo poprzez parametr do konstruktora, lub ewentualnie poprzez Ustawiacz właściwości. W ten sposób testy jednostkowe są niezwykle proste i bezpośrednie, a nawet nie wymagają wyśmiewania.

Wartość ustawienia może być następnie wstrzykiwana za pomocą inwersji kontenera Control (lub Dependency Injection), więc odbiorcy klasy Weather nie muszą jawnie dostarcz wartość skądś, ponieważ jest obsługiwana przez kontener.

To mi pomogło:

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

Możesz zawsze zawinąć bit odczytu w interfejsie i mieć określoną implementację wczytaną z pliku konfiguracyjnego. Następnie piszesz testy za pomocą Mock obiektów, aby zobaczyć, jak program radzi sobie ze złymi wartościami. Osobiście nie testowałbym tej konkretnej implementacji, ponieważ jest to kod. NET Framework (i zakładam-mam nadzieję-że MS już go przetestował).

System.Konfiguracja.Abstrakcje to piękna rzecz, jeśli chodzi o testowanie tego typu rzeczy.

Oto strona projektu GitHub z dobrymi przykładami: wpisz tutaj Opis linku

Oto strona NuGet: https://www.nuget.org/packages/System.Configuration.Abstractions/

Używam tego w prawie wszystkich moich projektach. NET.

Właściwie, myśląc o tym dalej, przypuszczam, że powinienem stworzyć klasę ConfigFileReader do użycia w moim projekcie, a następnie sfałszować ją w uprzęży testów jednostkowych?

Czy to normalne?

Najprostszą opcją jest owinięcie metod, które odczytują konfigurację w taki sposób, aby można je było zastąpić wartościami podczas testowania. Utwórz interfejs, którego używasz do odczytu config i poproś, aby implementacja tego interfejsu została przekazana jako parametr konstruktora lub ustawiona na obiekcie jako właściwość(tak jak w przypadku iniekcji zależności/inwersji sterowania). W środowisku produkcyjnym, pass w implementacji, która naprawdę czyta z konfiguracji; w środowisku testowym, pass w implementacja testowa zwracająca znaną wartość.

Jeśli nie masz opcji refaktoryzacji kodu pod kątem testowalności, ale nadal musisz go przetestować, Typemock Isolator zapewnia możliwość symulowania klas konfiguracji. NET framework, więc możesz po prostu powiedzieć " następnym razem, gdy Poproszę o taką i taką wartość appSettings, Zwróć tę znaną wartość."

Miałem ten sam problem,

Możesz użyć Nunit-console.exe c:\path1\testdll1.dll c:\path2\testdll2.dll

To działa dobrze, nawet jeśli oba biblioteki DLL wskazują na inną aplikację.configs ex testdll1.dll.config i testdll2.dll.config

Jeśli chcesz użyć NUnit project config i owinąć te dwie biblioteki DLL to nie ma mowy, że możesz mieć dwa configs

Musisz mieć project1.config jeśli twoim projektem Nunit jest project1.nunit w tym samym miejscu co Project1.nunit siada.

Hope this helps

Cóż, po prostu miałem ten sam problem... Chciałem przetestować projekt BL, który jest odwołany ze strony internetowej . ale chciałem przetestować tylko BL. Tak więc w zdarzeniu pre-build projektu testowego kopiuję aplikację.Pliki konfiguracyjne do folderu bin\debug i odwołaj się do nich z aplikacji.config ...