Introducción
Bienvenidos a la siguiente entrega de nuestra serie de publicaciones sobre ASP.NET Core y CQRS. En esta ocasión, nos centra...
For further actions, you may consider blocking this person and/or reporting abuse
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).
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!
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!
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!!
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!
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?
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:
Traducido al español:
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:
Traducido al español:
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:
Traducido al español:
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?
Totalmente de acuerdo con Ardalis. Yo siendo muy influenciado por Jimmy Bogard, están en completa sintonia, siguiendo esta diapositiva:
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.
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:
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...
Hola Omar!, gracias por tu comentario y el aporte
Milan y Nick son muy buenas referencias, seguro no es spaguetti como dices jaja
Saludos!.
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.
Excelente, conocí otra forma de hacer pruebas a la bd
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..?
¡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!
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?
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!