App.config para xUnit

Question

estoy escribiendo algunas xUnit pruebas para algunas clases de ayuda que se basa en algunos parámetros de configuración, normalmente se almacena en App.config o Web.config del proyecto de ejecución.

La configuración es similar a esto:

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
    <appSettings> 
    <add key="FileNamePattern" value="\\d{8}_\\w{4:20}\.png"/> 
    <!-- and the likes --> 
    </appSettings> 
</configuration> 

estoy corriendo xUnit 1.9, con el corredor de interfaz gráfica de usuario (xunit.gui.clr4.exe) y el corredor de la consola xUnit (en el servidor Jenkins CI). Actualmente, puedo "inyectar" estos valores de configuración en los entornos de prueba estableciendo manualmente los archivos xunit.gui.clr4.exe.config y xunit.console.exe.config); sin embargo, esto es tedioso y propenso a errores.

También podría simular estos ajustes de configuración en un dispositivo. Pero usar el mismo accesorio en 10 archivos diferentes es bastante repetitivo.

¿Hay una mejor manera de burlarse de configuración con xUnit, tales como proporcionar un archivo app.config para el proyecto de la prueba?

Answer 1

Si su código se supone que están en el app.config, entonces xUnit.net soportes que tienen ellos cableados hasta allí proporcionando uno (por lo general cuando las pruebas están en un archivo DLL, esto significa que usted obtiene un archivo AssemblyName.dll.config en los resultados del proyecto que el corredor carga como la configuración si existe en el momento de la carga).

Obviamente no hay daño para utilizar el principio de DI para eliminar dichas dependencias, en primer lugar, pero me gustaría decir que no vaya a jugar con el código antes de que realmente lo consigue bajo prueba en primer lugar.

para mantenerlo seco, poner el app.config en un lugar central y añadirlo como un enlace (a través de la flecha en el botón Abrir en el cuadro de diálogo). (Sí, hay mucho que no gusta de eso -. Use sólo si se siente su enfoque menos mal)

---

Una cosa a tener en cuenta es que los cambios no se les vuelve a cargar en el corredor de interfaz gráfica de usuario a menos que solicite que se recargue el conjunto.