uecko-control-tiempos/docs/arquitectura/testing.md

30 lines
1.7 KiB
Markdown
Raw Permalink Normal View History

# Estrategia de testing
## Objetivo
Definir qué se prueba, dónde y con qué nivel de profundidad.
## Criterios
Los tests priorizan comportamiento observable, contratos, invariantes y casos límite sobre detalles accidentales de implementación. Cuando cambie comportamiento observable se añaden o actualizan pruebas; los bugs incorporan una regresión cuando sea viable.
Cubrir según corresponda casos válidos e inválidos, límites, errores, idempotencia, autorización y concurrencia. Los tests deben ser deterministas, sin esperas arbitrarias y no se desactivan para obtener una suite verde.
## Niveles
Las pruebas unitarias cubren comportamiento de unidades y reglas aisladas. Las de integración cubren la colaboración entre componentes y persistencia cuando corresponda. Las E2E cubren flujos completos relevantes. La selección es proporcional al riesgo, alcance y capas afectadas.
## Validación por cambio
La evidencia se obtiene primero mediante la comprobación más acotada suficiente:
```text
test específico → tests del módulo o paquete → typecheck del módulo → lint del módulo → integración → E2E → validación global
```
La validación global procede ante paquetes compartidos, contratos públicos, configuración transversal, varios módulos o infraestructura común. El procedimiento de cierre y el informe de resultados se definen en la [guía de cierre](../guias/cierre-de-tareas.md).
## Fallos preexistentes
Distinguir fallos causados por el cambio, fallos preexistentes, fallos ajenos al área y validaciones no ejecutadas. No atribuir un fallo a una categoría sin evidencia ni ocultar errores de compilación, typecheck, lint, tests o build.