¿Cómo puedo probar las consultas de Dapper en .net core?

.net-core dapper unit-testing

Pregunta

Con el código dirigido al .NET Framework completo podría simular una IDbConnection y apuntarla a un DataSet burlado para probar que mis consultas se están ejecutando correctamente. De manera similar, si estuviera usando EntityFramework 6 podría hacer que DbSet se burlara de las IQueryables de retorno y probar mi lógica de capa de datos con eso.

Sin embargo, .net core no es compatible con DataSets (¿pero eso puede cambiar en el futuro ?).

Mientras tanto, ¿hay alguna forma de crear una colección de objetos a la que dapper pueda consultar usando un IDbConnection para probar la lógica de la consulta?

Respuesta aceptada

No, todo lo que dapper es, son los métodos de extensión en la parte superior de la clase IDbConnection .

No existe una implementación InMemory para esto ( IDbConnection ) (que entiende las cadenas de SQL).

Su mejor opción, sin embargo, si desea ejecutarlo completamente autónomo, sería crear un nuevo servidor SQL por cada vez que ejecute pruebas unitarias. Esto se puede hacer fácilmente con la imagen del acoplador que Microsoft ha creado para sqlserver: https://hub.docker.com/r/microsoft/mssql-server-linux/

o...

O migre al marco Entity, le permiten realizar pruebas unitarias contra una tienda de respaldo en la memoria.

¿por qué?

Dapper solo contiene algunas características útiles para generar SQL. De ninguna manera se abstrae de SQL. Y sql es simplemente texto para el código C #. no lo analiza ni lo ejecuta. Por lo tanto, usted no puede probar su código sql / dapper sin usar una base de datos detrás de él.

El marco de la entidad lo hace de manera diferente. intenta hacer, todo lo que quisieras hacer en una base de datos en C # code / abstraction (por ejemplo, el IDbCollection). Luego realizan 1 implementación que genera código sql y una implementación que usa memoria de respaldo en memoria. De esta forma, puedes probar tu código en forma unitaria.

Solución de Microsofts

Microsoft a menudo anuncia el uso del patrón de repositorio . Esta es básicamente una palabra costosa para resumir todas las llamadas / comandos de su base de datos en una clase separada e interconectar estas clases, y usar las interfaces en todas partes en el código (usando la inyección de dependencia). Ahora puede escribir pruebas unitarias que prueban que todo su código espera las consultas sql, para esta interfaz se hace una prueba para probar si realmente se llama el método.



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué