Estrategia de prueba del núcleo

1) Principios

Balance piramidal-trofeo. Base - Pruebas modulares y contractuales rápidas; arriba - componentes e integración; en la parte superior, una capa mínima pero valiosa de e2e.
Shift-left. Cuanto antes se atrapa un defecto (linter, análisis estático, property-based), más barato.
Deterministic by design. Controlamos el tiempo, la red, el random y las dependencias externas.
Economía de calidad. Cualquier prueba es un «seguro»: el objetivo es minimizar los costes totales (defectos + acompañamiento de pruebas).
Orientación al riesgo. La cobertura se concentra en invariantes comerciales y protocolos (contratos, idempotencia, consistencia).

2) Niveles de prueba y área de responsabilidad

2. 1 Unidad (modular)

Comprueba la lógica pura sin I/O.
Mojamos sólo los bordes (puerto/adaptador), utilizamos las fábricas para los datos.
Rápidos (≤50 -100 ms/test), paralelos.

2. 2 Contrato (proveedor ↔ consumidor)

Fijan los contratos API (HTTP/gRPC/event) entre los servicios.
Usamos un enfoque consumer-driven: los contratos se almacenan en VCS, se comprueban en el CI del proveedor.
Reducir la fragilidad de la integración e2e.

2. 3 Componentes (sobre el módulo, con almacenamiento real)

Ejecutamos parte del servicio con un BD/caché real en el contenedor (Testcontainers).
Validamos migraciones de esquemas, índices, transacciones, bloqueos.

2. 4 Integración/Sistema (rutas de acceso entre servicios)

Elevamos el conjunto de servicios en un entorno aislado.
Comprobamos invariantes de extremo a extremo: transaccionalidad, retraídas, idempotencia, manejo de errores.

2. 5 E2E (capa mínima «valiosa»)

Protocolos reales y entorno «como en venta», pero un conjunto escénico limitado: pago → confirmación → cableado; registro → verificación → entrada.
Usamos para lanzar lanzamientos y revertir fiches de alto riesgo.

3) Arquitectura de prueba

Puertos/adaptadores (Hexagonal). El núcleo de negocio no sabe acerca de HTTP/SQL; las dependencias se implementan a través de interfaces.
Inyección de tiempo/randoma. 'Clock', 'Random' - adicciones; en las pruebas fijamos.
Abstracción I/O configurable. Colas, DB, KMS - a través de interfaces con implementaciones de prueba.
Invariantes funcionales. Formulamos explícitamente las condiciones postales y los predicados: son más fáciles de probar y monitorizar.

4) Datos para pruebas

Factory/builder en lugar de fixtures JSON estáticos: menos fragilidad.
Sids idempotentes y reset-hook DB antes de la prueba (migraciones → truncate → seed).
Catálogos de casos: «normas», «bordes», «errores», «caos».
Sintética en lugar de PD reales: generadores, enmascaramiento, perfiles de privacidad.

5) Competencia e idempotencia

Pruebas de carrera (race): registros competitivos/reservas/bloqueos.
Comprobación de claves idempotentes (por ejemplo, '(operación, external_id)'): las llamadas repetidas no cambian el estado.
Retraídas y temporizaciones: garantizamos la corrección de errores temporales.

dedupe_key = hash(op + external_id)
if exists(executions, dedupe_key): return previous_result else:
reserve(dedupe_key)
result = do_operation()
store(executions, dedupe_key, result)
return result

6) Tiempo, tiempo de espera, zona horaria

Todos los tiempos almacenados son UTC; en las pruebas usamos 'FixedClock'.
Probamos los casos DST (tomas/pases del reloj), las ventanas del «día local».
Los Timautas verificamos con relojes monotónicos; simulamos un temblor NTP.

7) Sostenibilidad y caos

Fault-injection: errores de red, 5xx, latencia, degradación parcial (caché no disponible).
Pruebas de chaos en el entorno pre-prod: desactivación de nodos, sobrecarga de colas, roturas BGP/Anycast (emulación).
Políticas Fallback y Degradación UX: las pruebas deben confirmar la correcta «degradación graceful».

8) Rendimiento

Micro-benchmarks para algoritmos críticos (con fijación CPU/alloc).
Perfiles de carga: baseline (p50/p95), estrés (pico), extendido (soak) para fugas de memoria.
Regresión: build falla si p95 latencia es peor que baseline> X%.

9) Seguridad y cumplimiento

SAST/Lint: búsqueda de vulnerabilidades/antipatternos.
DAST/IAST: escenarios básicos en el stand (muestras XSS/SQLi/SSRF).
Secrets-scan: no hay claves/contraseñas en el código y los artefactos.
Pruebas de privacidad: ausencia de PD en los logotipos/rastros, cumplimiento de la «gestión de consentimiento», perfiles de anonimato para descargas.

10) Métricas de calidad y SLO

Test pass rate y flaky index (cole en pruebas inestables/semana).

• 90-100% para módulos de núcleo crítico,
• 70-80% para periféricos (con enfoque en invariantes).
• Release risk score: agregación: cambios en los archivos críticos × caída de los índices de referencia × nuevos flaky.
• Presupuesto erróneo: un conjunto de prod-SLO (aptime/error) con experimentación y frecuencia de lanzamiento.

11) CI/CD y gates

1. Lint/Format/TypeCheck

2. Unit + Property-based

3. Contract provider/consumer

4. Component (Testcontainers)

5. Integration + Perf smoke

6. Security (SAST/Secrets)

7. Build/Package + SBOM

8. Deploy to pre-prod + e2e + chaos smoke

Gates: parar por la caída de los contratos, el aumento de la latencia, las nuevas vulnerabilidades críticas.

Caché y sharding: aceleramos la pipelina a través del paralelismo y las corridas incrementales (por módulos modificados).

12) Flaky-test: detección y tratamiento

Piloto automático + quórum (2/3 carreras).
Detector de patrones de flack: dependencia del tiempo/random/expectativas implícitas.
Cuarentena con SLA: la prueba no bloquea las liberaciones, pero está obligada a ser corregida/reescrita en N días.
Tolerancia cero a la flaca en el «núcleo» de la vía crítica.

13) Property-based, mutación y pruebas de fase

Property-based: formulamos propiedades (conmutabilidad, idempotencia, monotonía), generadores de datos de frontera.
Mutation testing: medimos el «poder» de las pruebas (si matan las mutaciones introducidas).
Fuzzing: protocolos/parsers/formatos (JSON, Protobuf, CSV), especialmente en los límites de seguridad.

prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model

14) Observabilidad y relación con las pruebas

Seguimiento de pruebas (trace-id en los logs): es conveniente reproducir en pre-prod.
Los snapshots de métricas en la ejecución-ejecución son almacenados como artefacto.
Control de registros: sin campos sensibles, tamaño de los registros dentro de SLO.

15) Documentación y procedimientos

Test Handbook: dónde están las pruebas para ejecutar, cómo escribir fábricas, cómo actualizar contratos.
Runbooks: retroceso del incidente, diagnóstico rápido, retroceso del lanzamiento.
Catálogo de invariantes: lista de garantías del sistema y referencias a las pruebas/alertas correspondientes.

16) Check-list del arquitecto

1. ¿Describieron los invariantes del núcleo y las rutas críticas?
2. ¿Hay una matriz de niveles de pruebas y sus SLO (tiempo, estabilidad)?
3. ¿Los contratos son versionados y validados en CI por el proveedor y el consumidor?
4. El tiempo/random/red son controlables en las pruebas (FixedClock, Fault-injector)?
5. Configurados Testcontainers/BD aislada, ¿migraciones verificadas?
6. ¿Hay performance-basline y una puerta de regresión?
7. ¿Habilita SAST/Secrets-scan y revisiones de registros privadas?
8. ¿Se lleva un registro de flaky y hay un SLA para arreglar?
9. ¿La relación de las pruebas con el prod-SLO y el presupuesto erróneo se ha diseñado de manera transparente?
10. ¿Están documentados el runbook 'y el catálogo de invariantes?

Conclusión

La estrategia de prueba del núcleo no es una lista de herramientas, sino una capacidad arquitectónica: diseño de prueba, jerarquía estricta de niveles, datos gestionados, tolerancia a fallas y métricas incorporadas en CI/CD. Siguiendo las prácticas descritas, el equipo recibe comentarios rápidos y confiables, y las versiones se vuelven predecibles y seguras.