# 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.