2009-09-11 7 views
12

Si un ensamblaje contiene un archivo app.config, ConfigurationManager lo cargará mientras esté en el mismo directorio que el proyecto NUnit que se está ejecutando a través de NUnit-Gui. Para ilustrar, considere la siguiente estructura de carpetas.¿Cómo le indica a NUnit que cargue el archivo dll.config de un ensamblaje desde un directorio específico?

+ TestFolder 
    testProject.nunit 
    + AssemblyAFolder 
     assemblyA.dll 
     assemblyA.dll.config 
    + AssemblyBFolder 
     assemblyB.dll 
     assemblyB.dll.config 

Tanto AssemblyA y AssemblyB código de ejercicio que pone en ConfigurationManager. Si ejecuto estos ensambles de prueba de forma independiente en NUnit-Gui, ConfigurationManager resolverá correctamente los archivos de configuración local.

Sin embargo, si me carga testProject.nunit en NUnit-Gui (que contiene referencias tanto AssemblyA y AssemblyB), ConfigurationManager busca el archivo de configuración en TestFolder independientemente de la que el conjunto está ejecutando actualmente.

¿Hay alguna manera de ordenar a NUnit que vuelva a cargar la configuración de la aplicación a la presente en el directorio del ensamblaje actual?

Éstos son los contenidos de testProject.nunit:

<NUnitProject> 
    <Settings activeconfig="Debug" /> 
    <Config name="Debug" binpathtype="Auto"> 
    <assembly path="AssemblyAFolder\assemblyA.dll" /> 
    <assembly path="AssemblyBFolder\assemblyB.dll" /> 
    </Config> 
</NUnitProject> 
+0

No es una respuesta exacta, pero ¿podría unir los dos archivos de configuración y crear uno para todo el proyecto de prueba? – TrueWill

+0

Afortunadamente, esto debería funcionar en mi caso ya que estoy leyendo distintas secciones de configuración en cada ensamblaje.Tengo curiosidad por saber si hay un enfoque mejor o más general. –

Respuesta

1

El blog NUnit explica por qué los archivos de configuración se cargan la forma en que lo hacen. Básicamente, lo que dijeron fue que NUnit permite que el framework maneje los archivos de configuración y no hace ninguna gestión.

También puede usar el archivo testProject.config que se cargaría en su caso, para hacer referencia a los archivos de configuración para cada uno de los ensamblajes. Usar el atributo del archivo appSettings para agregar claves.

Una última alternativa es usar el configSource element attribute para usar la sección en uno de los archivos de configuración de conjuntos.

Espero que esto ayude.

3

El elemento configSourcesolution given by MarkLawrence es lo que estaba buscando, y funciona muy bien. Sin embargo, el desafío al implementar esta solución es cargar la configuración del ensamblaje cuando se ejecutan pruebas desde un proyecto NUnit explícito (como en my case), Y cuando se ejecutan las pruebas unitarias para un ensamble en forma aislada (sin proyecto explícito). Para lograr esto, se requieren las siguientes modificaciones en el diseño de mi archivo.

+ TestFolder 
    testProject.nunit 
    testProject.config 
    + AssemblyAFolder 
     assemblyA.dll 
     assemblyA.dll.config 
     assemblyA.dll.configfragment 
    + AssemblyBFolder 
     assemblyB.dll 
     assemblyB.dll.config 
     assemblyB.dll.configfragment 

Los archivos configfragment se crean para contener la configuración de montaje que fue una vez en los config archivos correspondientes. Posteriormente, los archivos config se modifican para contener solo un elemento configSource con una ruta relativa al archivo configfragment correspondiente. Tenga en cuenta que la única vez que este enfoque no funciona es cuando assemblyA.dll y assemblyB.dll requieren la misma sección de configuración, ya que surgirá un conflicto al crear testproject.config.

Después de experimentar con este enfoque, decidí confiar en la generación de la configuración de ensamblaje en tiempo de ejecución y eliminar todos los archivos de configuración estáticos. Aquí hay un código que demuestra cómo generar la configuración y hacerla accesible independientemente de cómo se cargue el ensamblaje bajo prueba.

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

Mediante el uso de la sobrecarga ConfigurationManager.OpenExeConfiguration() que no acepta un camino, que carga la configuración del directorio de trabajo del programa de control que cambia en función de la forma de ejecutar las pruebas NUnit. Además, el bloque try/finally garantiza que la configuración de su conjunto no interfiera con otras pruebas, que pueden o no requerir dicha configuración.

Por último, para el uso dentro de una prueba de unidad:

[Test] 
void VerifyFunctionality 
{ 
    WithConfigurationFile(delegate 
    { 
     // implement unit test and assertions here 
    }); 
} 

espero que esto ayude a otros que pueden haber encontrado problemas similares!

2

utilizar el atributo configfile en el nivel de configuración en el archivo de .nunit:

 

<Config name="Debug" configfile="myconfigfilenamegoeshere.config /> 
 
5

Nunit no es capaz de localizar la ruta del archivo de App.config en nuestro proyecto. Por lo tanto, debemos indicarle manualmente a Nunit dónde se encuentra el archivo App.config en nuestro proyecto (obviamente en la carpeta raíz).

En mi caso, la estructura del proyecto es la siguiente

 +ProjectWEBApp//web pages 
     +Modules 
     +aspx pages 
     +web.Config 

    +projectBusinesslogic //business logic .cs files 
     +Modules 
     +.cs 

     +ProjectTestName// a seperate Nunit test cases project 
     +Modules 
     +App.Config 

la ProjectWebApp utiliza las referencias de projectBusinesslogic que contiene la lógica de negocio. + ProjectTestName usa la referencia de projectBusinesslogic para realizar pruebas en la lógica de negocios. Los problemas comienzan aquí, el proyecto de prueba Nunit necesita su propio archivo app.config. no va a usar el archivo web.config como en el caso de projectBusinesslogic, por lo que cuando se ejecuta Nunit se le pedirá un error

-null excepción de referencia ....... instantánea objeto no establecida ... ........

Solución- al ejecutar la interfaz gráfica de usuario Nunit

  1. Proyecto-> Editar una nueva ventana emergente se abrirá
  2. Propiedades -> General-> archivo de configuración Nombre-> agregue su app.config Nombre de archivo
  3. Archivo-> guardar y cerrar la ventana emergente
  4. EN Nunit Gui-Archivo-> Recargar Proyecto

y que es la solución simple para su problema

+1

¡Es increíble mi problema de que todo este tiempo no haya estado en el paso 4! ¡¡¡Gracias!!! – craastad

+0

Gracias, sus pasos 1 - 4 fue todo lo que necesitó! – Flea

0

En realidad, si está utilizando NUnit y un corredor dentro de Visual Studio, puede guardar su valor en un App.config en su proyecto de prueba. A continuación, añadir esta línea a su evento posterior a la generación:

copia/Y “$ (ProjectDir) App.config” “$ (TargetDir) $ (TargetFileName) .config”

Al acceder a la ConfigurationManager en su pruebas, NUnit pasará los valores en su app.config a .Net en el método de inicialización.

Cuestiones relacionadas