Estrategia de Pruebas Automáticas — Sprint 2

Cada funcionalidad entregada tiene al menos dos pruebas automáticas: una de happy path y otra de flujo alternativo. Las pruebas corren en el CI (GitHub Actions) en cada PR, y un merge se bloquea si fallan.

Tabla de estrategia

Funcionalidad	Tipo de prueba	Justificación
HU-16 Consecutivo único	Unitaria + Concurrencia	El formato es regla pura (unitaria); la unicidad bajo concurrencia exige hilos con SELECT FOR UPDATE real.
HU-15 Validación obligatoria	Integración (vista)	La regla vive en el borde HTTP; probar la vista garantiza que aplica aun sin el navegador.
HU-06/07 Ítems	Integración (formset)	El formset y la transacción encabezado+ítems se prueban juntos: "todo o nada".
HU-19 Notificación correo	Integración con mock SMTP	Verifica que el correo se dispara sin enviar correo real.
HU-34 Aviso antes de enviar	Escenario (plantilla)	Happy: el modal y su resumen están en el HTML. Alt: envío inválido no radica; borrador omite el aviso.
HU-29 Vistas analíticas	Integración (SQL)	Happy: las vistas desnormalizan y agregan bien. Alt: requerimiento sin ítems reporta 0; la vista es de solo lectura.
HU-22 Ficha completa	Integración + permisos	Happy: el analista ve todo el detalle. Alt: solicitante 403, consecutivo inexistente 404.
HU-21 Filtros de la bandeja	Integración (vista con GET)	Los filtros son una consulta: se prueba la vista con datos sembrados en varias áreas, prioridades y fechas. Alt: valores inválidos y rango invertido no rompen la bandeja.
HU-13 Proveedores sugeridos	Integración (formulario + transacción)	La regla "fila empezada = nombre y teléfono" vive en el formulario; probar el POST completo confirma que entra en la misma transacción de la radicación.
HU-14 Productos sustitutos	Unitaria (modelo) + integración	La regla "sí exige descripción" se prueba en el modelo (vale aunque se cree desde otro lado) y en el formulario.
Comandos de gestión	Unitaria (call_command)	cargar_catalogos, crear_perfiles y crear_rol_analitica. El de PostgreSQL usa un cursor simulado para verificar el SQL que emite.

Happy path + alternativo por HU del Sprint 2

• HU-34 — happy: modal presente / alt: envío inválido no radica
• HU-29 — happy: vista desnormaliza y agrega / alt: sin ítems reporta 0; solo lectura
• HU-22 — happy: ficha completa / alt: 403 a solicitante y 404 a consecutivo inexistente
• HU-21 — happy: filtra por área, prioridad y fechas, y ordena / alt: sin coincidencias avisa; valor inválido o rango invertido no se aplican
• HU-13 — happy: guarda hasta 3 proveedores con teléfono / alt: fila incompleta o teléfono inválido bloquean la radicación
• HU-14 — happy: guarda los sustitutos / alt: «sí» sin descripción bloquea; «no» descarta lo escrito
• HU-35 — happy: el solicitante recibe su confirmación (NotificacionConfirmacionSolicitanteTests) / alt: cuenta sin correo o falla del SMTP no tumban la radicación
• HU-25 — happy: busca entre lo propio por consecutivo o descripción (MisRequerimientosTests) / alt: no muestra lo ajeno
• HU-30 — happy: siembra y exporta los datos del tablero (SembrarDemoTests, ExportarAnaliticaTests) / alt: se niega con DEBUG=False

Extras del Sprint 2

• Corregir hallazgos de análisis estático del Sprint 1 → Ruff pasa limpio.
• Correr pruebas en cada PR → configurado en ci.yml (jobs calidad, seguridad, pruebas).
• Bloquear merge si fallan → la protección de rama de main exige los 3 checks en verde y una aprobación.
• Control de coverage → coverage en el pipeline con mínimo del 90%.

Coverage en el CI

• coverage está en requirements-dev.txt y su configuración en pyproject.toml ([tool.coverage.*]): se mide solo el código propio, sin migraciones ni pruebas, con cobertura de ramas (branch = true).
• El job Pruebas automatizadas (Django) corre coverage run manage.py test y luego coverage report, que falla si la cobertura baja del 90% (fail_under). Como el merge exige el CI en verde, un PR que baje la cobertura no entra a main.
• Cada ejecución publica el reporte HTML como artefacto reporte-cobertura (pestaña Actions → la ejecución → Artifacts), con el detalle línea por línea.

Por qué 90%: al activar el control la cobertura estaba en 86%; los comandos de gestión (cargar_catalogos, crear_perfiles, crear_rol_analitica) estaban en 0%. Con sus pruebas subió a 97%. El mínimo se fija en 90% para dejar margen a código difícil de probar (configuración por entorno) sin aceptar que una funcionalidad nueva entre sin pruebas.

Cómo verlo en local:

pip install -r requirements-dev.txt
DB_ENGINE=sqlite coverage run manage.py test
coverage report
coverage html    # abre htmlcov/index.html