1. Resumen general
- Compartir cómo construir pruebas unitarias con el enfoque Sociable Test (integrado con una DB real)
- Los ORM como TypeORM tienen problemas de seguridad de tipos, por lo que se necesitan pruebas usando una DB real
2. Solitary Test vs Sociable Test
- Comparación
- Solitary Test reemplaza las dependencias con mocks para probar de forma aislada (es rápido, pero puede diferir del entorno real)
- Sociable Test prueba junto con dependencias externas reales (DB), lo que permite asegurar confiabilidad (es más lento, pero detecta antes problemas realistas)
- Limitaciones de Solitary Test
- Con mocking es difícil detectar por completo los problemas de interacción con la DB real
- Los problemas de verificación de tipos en TypeORM pueden causar errores en tiempo de ejecución
- Necesidad de Sociable Test
- Al integrarse con una DB real, permite validar consultas complejas, transacciones y problemas de configuración de relaciones
- Configurando una base de datos de pruebas, se pueden ejecutar pruebas de aislamiento de datos mediante transacciones
- Ventajas y precauciones de las DB Sociable Test
- Ventajas: pruebas más confiables, detección temprana de problemas relacionados con ORM, verificación de inconsistencias de esquema
- Precauciones: menor velocidad de prueba, configuración del entorno más compleja, necesidad de gestionar transacciones
3. Implementación de pruebas integradas con DB en NestJS
- Configuración
- Configurar la conexión a una DB de pruebas usando MySQL
- Usar transacciones para hacer rollback de los cambios de cada prueba
- Uso del ciclo de vida del framework de pruebas Jest
- Uso de
beforeAll / beforeEach / afterEach / afterAll
- Configuración de la inicialización y conexión de la DB, así como del inicio y cierre de transacciones
4. Conclusión
- Al escribir pruebas unitarias, conviene combinar adecuadamente Solitary Test y Sociable Test
- Sociable Test puede ser de gran ayuda para prevenir problemas relacionados con ORM
Aún no hay comentarios.