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.
1.7 KiB
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:
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.
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.