visual studio - El problema con NUnit y app.config
visual-studio app-config (8)
- Ir a NUnit / Project / Edit ...
- En el panel de propiedades de configuración, vaya a Nombre del archivo de configuración
- Pon tu nombre de ensamblador .dll.config
NB: si no funciona, intente agregarle una ruta, por ejemplo, bin / Debug / yourAssemblyName .dll.config
Se actualizará el archivo de proyecto de prueba yourAssemblyName .nunit.
Y sí, asegúrese de que App.config en su proyecto de prueba coincida con lo que accede en la prueba, es decir,
[Test]
public void TestConn()
{
var sss = ConfigurationManager.AppSettings["TestKey"];
}
App.config
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="TestKey" value="testKeyValue"/>
</appSettings>
</configuration>
Cuando ejecuto una prueba simple en la conexión a DB, recibo un error en NUnit:
[Test]
public void TestConn()
{
string connectionString = ConfigurationManager.ConnectionStrings["FertigungRead"].ConnectionString;
SqlConnection connection = new SqlConnection(connectionString);
connection.Open();
Assert.AreEqual(ConnectionState.Open, connection.State);
connection.Close();
}
System.NullReferenceException: referencia de objeto no establecida en una instancia de un objeto.
en linea:
connectionString = ConfigurationManager.ConnectionStrings["FertigungRead"].ConnectionString;
¿Puedo usar ConfigurationManager en las pruebas?
¿Por qué necesita una prueba de unidad para ver si SqlConnection funciona? Debes probar tu código, no el de Microsoft. Realmente no veo el punto de verificar si la cadena de conexión es correcta en sus pruebas de unidad. La configuración utilizada por las pruebas unitarias no es la misma que la que utilizará su código de producción.
Sin embargo, en general, si necesita algunos datos de configuración para las pruebas unitarias, cree un archivo app.config en el proyecto de prueba. Rellene los elementos appSettings y connectionStrings, etc. con los valores adecuados para su entorno de prueba. Sin embargo, no se moleste en probar si ConfigurationManager o SqlConnection funcionan. Simplemente creará un código que debe mantener, pero eso no verifica realmente ninguno de los códigos de producción que está escribiendo.
Cuando se usa un archivo de configuración en el proyecto en el que se ejecuta una prueba, se deben seguir convenciones de denominación específicas.
El nombre del archivo de configuración debe ser el nombre del archivo de ensamblaje con la extensión de configuración. Por ejemplo, el archivo de configuración utilizado para ejecutar MyUnitTest.tests.dll debe llamarse MyUnitTest.tests.dll.config y debe estar en el mismo directorio que MyUnitTest.nunit
También podemos configurar esto en preconstrucciones como a continuación.
copy $(SolutionDir)path-to-main-project/Web.config $(ProjectDir)App.config
El hombre echa un vistazo a: http://nunit.net/blogs/?p=9
Como él sugirió, puse un MyProjectTests.dll.config en la raíz del proyecto y todo funciona.
Un ejemplo de mi archivo de configuración es:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="TestKey" value="Ok!"/>
</appSettings>
</configuration>
Y estoy usando el simple: ConfigurationManager.AppSettings["TestKey"];
Me gustaría añadir un punto. Hay una nota en la documentación de nunit y, según el escenario de uso, debe realizarse la asignación de nombres y la ubicación del archivo de configuración. Estuve atrapado en este tema por un tiempo.
La documentación dice:
Si se está cargando un único ensamblaje, entonces el archivo de configuración recibe el nombre del archivo de ensamblaje con la extensión de configuración. Por ejemplo, el archivo de configuración utilizado para ejecutar nunit.tests.dll debe llamarse nunit.tests.dll.config y debe estar ubicado en el mismo directorio que la dll.
Si se está cargando un proyecto NUnit, el archivo de configuración usa el nombre del archivo del proyecto con la extensión cambiada a config. Por ejemplo, el proyecto AllTests.nunit requeriría un archivo de configuración llamado AllTests.config, ubicado en el mismo directorio que AllTests.nunit. Se sigue la misma regla al cargar proyectos o soluciones de Visual Studio.
Sí tu puedes. app.config asegurarse de que la configuración a la que hace referencia en sus pruebas exista realmente en el app.config del proyecto de prueba.
En otras palabras, el proyecto en el que se encuentra la prueba no tiene una cadena de conexión "FertigungRead" definida en su app.config .
Una forma de hacer esto es agregar el app.config del sistema bajo prueba al proyecto de prueba como un enlace , de esta manera cualquier cambio suceda en ambos proyectos.
Sus pruebas de unidad aún deberían funcionar siempre que tenga la misma configuración para su proyecto de prueba que para su proyecto principal.
Yo sugeriría usar un evento de construcción previa en su proyecto de prueba para copiar el archivo de configuración de su aplicación al proyecto de prueba. Esto ahorra tener que mantener dos conjuntos de configuración.
copie $ (SolutionDir) path-to-main-project / Web.config $ (ProjectDir) App.config
Vea mi respuesta nunit y configuraciones Debe decirle a nunit cuál es el nombre del archivo de configuración. busca namespace.config por defecto que cose