David
0e7106f30c
- Updated "Ficha del proyecto UECKO.md" to clarify architectural boundaries and continuity rules. - Revised "README.md" to enhance structure and clarify sources of truth for documentation. - Improved "backend.md" with clearer definitions of responsibilities and architectural layers. - Streamlined "convenciones.md" to emphasize naming conventions and TypeScript best practices. - Enhanced "datos-persistencia.md" to specify persistence rules and data integrity measures. - Updated "frontend.md" to define frontend rules and state management practices. - Refined "testing.md" to clarify testing levels and validation processes. - Revised "vision-general.md" to outline system architecture and module boundaries more clearly.
30 lines
1.7 KiB
Markdown
30 lines
1.7 KiB
Markdown
# 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.
|