Unidad de prueba del archivo app.config con NUnit

Question

¿Cuando están probando una aplicación que se basa en valores de un archivo app.config? ¿Cómo comprueba que esos valores se leen correctamente y cómo reacciona su programa a los valores incorrectos ingresados ??en un archivo de configuración?

Sería ridículo tener que modificar el archivo de configuración de la aplicación NUnit, pero no puedo leer los valores de la aplicación.config que quiero probar.

Edit: Creo que debería aclarar tal vez. No me preocupa que el ConfigurationManager no pueda leer los valores, pero me preocupa probar cómo reacciona mi programa a los valores leídos.

Answer 1

Por lo general, aíslo las dependencias externas, como la lectura de un archivo de configuración en su propia clase de fachada con muy poca funcionalidad. En las pruebas, puedo crear una versión simulada de esta clase que implementa y usarla en lugar del archivo de configuración real. Puedes crear tus propias maquetas o usar un framework como moq o rhino para esto.

De esa manera, puede probar fácilmente su código con diferentes valores de configuración sin escribir pruebas complejas que primero escriben archivos de configuración XML. El código que lee la configuración es generalmente tan simple que necesita muy pocas pruebas.

Answer 2

Puede modificar su sección de configuración en tiempo de ejecución en su configuración de prueba. E.g:

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

Por supuesto, puede configurar sus propios métodos de ayuda para hacer esto de manera más elegante.

Answer 3

Puede llamar al método de configuración de ConfigurationManager.AppSettings para establecer los valores necesarios para esa prueba de unidad en particular.

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

Cuando la prueba de la unidad se ejecute, utilizará estos valores para ejecutar el código

Answer 4

Puedes leer y escribir en el archivo app.config con la clase ConfigurationManager

Answer 5

Me encontré con problemas similares con web.config .... Encuentro una solución interesante. Puede encapsular la función de lectura de configuración, por ejemplo, algo como esto:

public class MyClass {

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

//...

}

Y luego usamos normalmente

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

pero en la prueba de unidad inicializar " anular " la función como esta:

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

Más sobre esto:

http: // rogeralsing. com / 2009/05/07 / la forma más simple de inyección de dependencia configurable /

Answer 6

Una solución más elegante es utilizar la inyección de dependencia simple en los ajustes de configuración. En mi opinión, esto es más limpio que tener que burlarse de una clase de lectura de configuración / envoltura, etc.

Por ejemplo, diga una clase " Tiempo " requiere un " ServiceUrl " para funcionar (por ejemplo, digamos que llama a un servicio web para obtener el clima). En lugar de tener alguna línea de código que vaya activamente a un archivo de configuración para obtener esa configuración (ya sea que ese código esté en la clase de clima o en un lector de configuración separado que pueda ser burlado según algunas de las otras respuestas), la clase de clima puede permitir la configuración que se inyectará, ya sea a través de un parámetro al constructor, o posiblemente a través de un establecedor de propiedades. De esa manera, las pruebas unitarias son extremadamente simples y directas, y ni siquiera requieren burlas.

El valor de la configuración se puede inyectar utilizando un contenedor de Inversión de control (o inyección de dependencia), por lo que los consumidores de la clase Weather no necesitan suministrar explícitamente el valor desde algún lugar, ya que el contenedor lo maneja.

Answer 7

Eso me funcionó:

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

Answer 8

Siempre puede envolver el bit de lectura en una interfaz y hacer que una implementación específica se lea del archivo de configuración. Luego, escribiría pruebas utilizando Objetos simulados para ver cómo el programa maneja valores incorrectos. Personalmente, no probaría esta implementación específica, ya que este es el código de .NET Framework (y supongo que, con suerte, la MS ya lo ha probado).

Answer 9

System.Configuration.Abstractions es una cuestión de belleza cuando se trata de probar este tipo de cosas.

Aquí está el sitio del proyecto GitHub con algunos buenos ejemplos: ingrese la descripción del enlace aquí

Aquí está el sitio de NuGet: https://www.nuget.org/packages /System.Configuration.Abstractions/

Lo uso en casi todos mis proyectos .NET.

Answer 10

En realidad, pensando más en ello, supongo que lo que debo hacer es crear una clase ConfigFileReader para usar en mi proyecto y luego fingirla en el arnés de prueba de la unidad.

¿Es eso lo que se suele hacer?

Answer 11

La opción más sencilla es envolver los métodos que leen la configuración de modo que pueda sustituir los valores durante la prueba. Cree una interfaz que use para leer la configuración y haga que una implementación de esa interfaz se pase como un parámetro de constructor o se establezca en el objeto como una propiedad (como lo haría usando la inyección de dependencia / inversión de control). En el entorno de producción, pase una implementación que realmente lea de la configuración; en el entorno de prueba, pase una implementación de prueba que devuelva un valor conocido.

Si no tiene la opción de refactorizar el código para la capacidad de prueba y aún necesita probarlo, el Aislador de Typemock ofrece la posibilidad de simular las clases de configuración del marco .NET para que pueda decir "la próxima vez que solicite". tal y tal valor de configuración de aplicación, devuelve este valor conocido. "

Answer 12

Tuve el mismo problema,

puedes usar Nunit-console.exe c: \ path1 \ testdll1.dll c: \ path2 \ testdll2.dll

esto funciona bien incluso si ambas dll apuntan a diferentes aplicaciones.configs ex testdll1.dll.config y testdll2.dll.config

Si desea utilizar la configuración del proyecto Nunit y envolver estos dos archivos DLL, no hay forma de que pueda tener dos configuraciones

tienes que tener project1.config si tu proyecto de Nunit es project1.nunit en la misma ubicación donde se encuentra Project1.nunit.

espero que esto ayude

Answer 13

Bueno, acabo de tener el mismo problema ... Quería probar un proyecto BL al que se hace referencia desde un sitio web. Pero quería probar el BL solamente. Por lo tanto, en el evento previo a la compilación del proyecto de prueba, copio los archivos de la aplicación.Configurar en la carpeta bin \ debug y los remito desde la aplicación.config ...