DEV Community

Pruebas de Integración en ASP.NET Core y CQRS: Parte 8

Isaac Ojeda on April 13, 2022

Introducción Bienvenidos a la siguiente entrega de nuestra serie de publicaciones sobre ASP.NET Core y CQRS. En esta ocasión, nos centra...
Collapse
 
torresomarr profile image
Omar Torres • Edited

Gracias Isaac, la vdd he aprendido bastante con los blogs que escribiste, quería aparte de agradecerte, compartirte que he tratado de implementar lo mismo que hiciste aquí pero con Xunit y Testcontainers, te lo comparto por si gustas ver mi spaguetti xD.

Me base en videos de Milan Jovanović y Nick Chapsas.

github.com/TorresOmarr/MinimalApiA...

Collapse
 
isaacojeda profile image
Isaac Ojeda

Hola Omar!, gracias por tu comentario y el aporte

Milan y Nick son muy buenas referencias, seguro no es spaguetti como dices jaja

Saludos!.

Collapse
 
torresomarr profile image
Omar Torres

jeje gracias, lo que quiero hacer en un futuro es ver la manera de agrupar por dos o mas collections test que no se relacionen entre si correrlos en paralelo por si llegasen a tardar mucho, pero eso lo hare solo si se requiere.

Collapse
 
mrdave1999 profile image
Dave Roman

Hola Isaac, gracias por el tutorial.

Una observación, resetear la base de datos después de finalizar cada prueba no es factible cuando se tiene un número de tablas significativo (como por ejemplo, 100 tablas).

Collapse
 
isaacojeda profile image
Isaac Ojeda

Hola Dave!

Habría que hacer la prueba (o ya lo confirmaste?), respawn es lo suficientemente inteligente que la forma que hace el reset es haciendo puros DELETE's de forma jerárquica, por lo cual no deshabilita constraints ni nada para ejecutar un "restore point".

Buscando por internet no encontré ninguna queja en bases de datos gigantes, tengo un proyecto con mucha deuda técnica donde tengo pendiente agregar pruebas de integración, valdría la pena ser conejillo de indias.

Saludos!

Collapse
 
mrdave1999 profile image
Dave Roman • Edited

Sí, lo probé con una base de datos de 60 tablas por medio de MariaDb, el problema radica que es más costoso crear y eliminar tablas que borrar datos de las tablas. Por eso decidí utilizar Respawn, por lo que las pruebas de integración se ejecutan más rápido.

Aquí por ejemplo el OP no desea crear y eliminar la base de datos después de cada prueba porque es costoso: stackoverflow.com/questions/647115.... Al final el OP decidió crear sus scripts SQL para borrar datos de las tablas, aunque en los comentarios mencionaron la biblioteca Respawn.

Saludos!

Thread Thread
 
isaacojeda profile image
Isaac Ojeda

Mea culpa Dave, este código está desactualizado a como lo dejé al final, creí que te referías que no era óptimo utilizar Respawn con muchas tablas.

Revisando el post ni uso respawn 😅.

Me urge actualizar este post ya que no es la primera pregunta de este tipo, realmente en este ejemplo uso SQLite y al final lo quité y lo dejé con SQLServer y Respawn.

Totalmente cierto lo que dices, eliminar y recrear TODA la base de datos por cada prueba, no conviene para nada. Respawn es la solución.

Saludos!!

Thread Thread
 
mrdave1999 profile image
Dave Roman

Esperaré con ansia la actualización del post, me hubiera ahorrado dolores de cabeza 😅 (dos días sufriendo sobre como configurar las pruebas de integracion haha 😰)

Saludos Issac!

Thread Thread
 
isaacojeda profile image
Isaac Ojeda

En este proyecto las tengo como quedaron al final en esta serie de posts.

En qué estás batallando o tienes dudas con pruebas de integración?

Thread Thread
 
mrdave1999 profile image
Dave Roman • Edited

Actualmente no estoy batallando con las pruebas de integración.

Con respecto sí tengo dudas con las pruebas de integración, digamos que sí, aunque es más a nivel conceptual...
Sí por ejemplo creo una prueba automatizada, en la cual se encarga de verificar sí las variables de entorno se cargaron correctamente desde el archivo ".env", entonces la prueba sería "unitaria" o de "integración"?
Adjunto el ejemplo: github.com/MrDave1999/dotenv.core/...

Al principio pensé que era una "prueba unitaria" pero después de revisar el concepto de prueba unitaria de esta página: ardalis.com/unit-test-or-integrati...

Mi pensamiento cambió cuando leí esta parte:

"It’s a test that has zero dependencies on infrastructure, or on code outside of your control. "

Traducido al español:

"Es una prueba que tiene cero dependencias de la infraestructura, o en el código fuera de su control."

Sí seguimos esta definición, entonces la prueba que pasé es de integración porque depende del "sistema de archivos" (esto sería una dependencia de la "infraestructura").

Y la parte que me impresionó fue esta pregunta que está al final del artículo:

Q: Does the System Under Test (SUT) require an installed and configured and available database in order to run the test successfully?

A: If yes, then it’s an Integration Test

Traducido al español:

P: ¿Requiere el sistema bajo prueba (SUT) una base de datos instalada, configurada y disponible para poder ejecutar la prueba con éxito?

R: En caso afirmativo, se trata de una prueba de integración.

Esto significa que sí el código a probar depende de un proveedor de base de datos en memoria de EF Core (o de un "proveedor de SQLite en memoria de EF Core"), entonces la prueba sería de integración, debido a que al menos son base de datos que requieren configuración para ejecutar la prueba con éxito. Y esto me pareció curioso, porque muchas personas usan estos proveedores para crear sus pruebas unitarias pero con esta definición, sería una prueba de integración.
Sin embargo, el mismo autor también creó otro artículo que menciona lo mismo: weeklydevtips.com/episodes/024

Cito la parte importante:

" If you have a test that tests more than one class working together, or that depends on code that isn't yours (like, say, an ORM), it's not a unit test. It's an integration test."

Traducido al español:

"Si tienes una prueba que comprueba más de una clase trabajando juntas, o que depende de código que no es tuyo (como, por ejemplo, un ORM), no es una prueba unitaria. Es una prueba de integración."

Lo que dice el autor tiene mucho sentido, sí el código depende de una dependencia compleja como un proveedor de SQLite, entonces la ejecución del código a probar depende de ello, por lo que no puedes probarlo de manera unitaria.

Pienso que el objetivo de la prueba unitaria es enfocarse en el código a probar y no en sus dependencias complejas.

No sé que pienses sobre esto. ¿Qué opinas?

Thread Thread
 
isaacojeda profile image
Isaac Ojeda • Edited

Totalmente de acuerdo con Ardalis. Yo siendo muy influenciado por Jimmy Bogard, están en completa sintonia, siguiendo esta diapositiva:

Image description

Yo paso siempre a hacer pruebas de integración, siempre. Pero si tengo reglas del dominio que hice "Push Down" (como dice en la conferencia) solo en esa parte, suelo hacer pruebas unitarias, solo probando eso.

Image description

Me tiene sentido, porque solo pruebo una clase, que dice que debe comportarse de x o y forma (En el repositorio mencionado antes tengo un ejemplo de eso).

Dado a que siempre hago CQRS, siempre tiendo a probar cada Query y Comando siguendo el flujo completo (middlewares, behaviours, etc). Pero si en un comando existe una lógica compleja, por lo regular lo mando fuera del comando (ya sea un domain service o el mismo entity) y este lo pruebo por si solo en un Unit Testing.

La verdad no me pongo tan intenso en la diferencia de estos dos, por lo regular te digo, termino haciendo pruebas de integración porque hago la prueba directamente en el Query o Comando, en casos muy específicos suelo necesitar probar comportamientos complicados, por que no siempre sigo DDD al pie de la letra, al final siempre termina todo en el Comando.

Jimmy Bogard tiene muy buen contenido, te recomiendo estas platicas:

Collapse
 
jecacarvajal profile image
JecaCarvajal

Excelente, conocí otra forma de hacer pruebas a la bd

Collapse
 
aalvarezd profile image
aalvarezd

Buen articulo!
solo tengo una consulta, para el método GetAccessToken() no seria mejor utilizar una llamada http directo al endpoint de autenticación en vez de simularlo con el SendAsync..?

Collapse
 
isaacojeda profile image
Isaac Ojeda

¡Gracias!

Podría ser, pero mi intención en esa parte es probar otros métodos y no la autenticación en si, por eso lo tengo en la parte Arrenge.

Pero es depende como lo veas, si quieres hacer la llamada al Endpoint en lugar de al comando directamente, funciona perfectamente también.

¡Saludos!

Collapse
 
kiquenet profile image
Kiquenet

una base de datos SQLite para tests y SQL Server en producción no es una buena práctica ? SQLite no tiene soporte para stored procedures, SQL server si.

Quizá es viable Sql Server en Linux, con Docker?

Collapse
 
isaacojeda profile image
Isaac Ojeda

Sí, no es buena idea, esta serie de posts empezaron como algo sencillo y corto y resultó ser una serie larga que abarqué temas que no pensé que lo iba a hacer.

De hecho en este post moví todo a SQL Server (incluso las pruebas).

Si son pruebas de integración, debe de ser SQL Server para sí probar la integración jeje.

Debería de actualizar este post porque sí confunde.

Saludos!

Collapse
 
isaacojeda profile image
Isaac Ojeda

Citando post mencionado

Image description