System Design
Explica cómo derivar una estrategia de pruebas desde riesgos, requisitos, contratos, estados y atributos de calidad, distribuyendo cobertura entre niveles.
Una estrategia de pruebas no comienza escogiendo frameworks. Comienza identificando qué afirmaciones del diseño deben demostrarse, qué riesgo cubre cada prueba y qué evidencia permitirá decidir.
Diseñar para probar significa hacer observables y controlables las reglas, estados, contratos y fallos importantes. La estrategia conecta necesidades con evidencia sin depender de una pirámide aplicada mecánicamente.
objetivo o riesgo
→ requisito verificable
→ escenario
→ oráculo esperado
→ nivel de prueba
→ ambiente y datos
→ evidenciaUna prueba sin criterio puede ejecutar mucho código y demostrar muy poco.
Ejemplo:
RNF-04
El 95 % de las consultas de catálogo debe responder en menos de 300 ms
con 150 solicitudes por segundo y catálogo de 100 000 productos.
Evidencia
→ prueba de carga con distribución realista
→ p50, p95, p99 y errores
→ uso de CPU, memoria, conexiones y base de datos
→ resultado comparado con el umbral“Probar que sea rápido” no define carga, percentil, ambiente ni criterio.
Comprueban reglas, invariantes, transformaciones y decisiones de forma aislada y rápida.
Buenos candidatos:
No requieren que cada clase tenga una prueba propia. La unidad es el comportamiento pequeño que aporta confianza.
Comprueban colaboración con infraestructura real o representativa:
Una prueba con repositorio totalmente simulado no demuestra que claves, transacciones o consultas funcionen.
Protegen compatibilidad entre consumidor y proveedor.
Pueden verificar:
No sustituyen una prueba de integración: un contrato válido puede estar implementado de forma incorrecta.
Demuestran recorridos críticos entre componentes desplegados. Son valiosas para unas pocas capacidades de alto valor, pero suelen ser más lentas, frágiles y difíciles de diagnosticar.
Ejemplos:
Permiten descubrir problemas que no estaban formalizados y validar con negocio u operación que el resultado es útil.
Incluyen rendimiento, seguridad, accesibilidad, usabilidad, resiliencia, recuperación, compatibilidad y migración.
Toda prueba necesita decidir qué resultado es correcto.
entrada
+ estado inicial
+ evento
→ salida
+ estado final
+ efectos permitidos
+ efectos prohibidosEjemplo de cancelación:
Comprobar solo el status HTTP no demuestra las invariantes.
Tiempo, aleatoriedad, IDs y servicios externos deben poder controlarse sin alterar las reglas.
Expón eventos, logs, métricas o consultas de diagnóstico suficientes. No conviertas tests en consultas directas a detalles internos innecesarios.
Contratos pequeños y responsabilidades cohesionadas facilitan aislar fallos.
Fixtures, factories o builders deben expresar intención y evitar objetos gigantes irrelevantes.
Permiten repetir pruebas y recuperarse de incertidumbre.
Cada prueba debe conocer qué datos crea, reutiliza y elimina. Paralelismo no debe introducir interferencia accidental.
No todo merece la misma inversión.
riesgo alto + detección difícil
→ pruebas profundas, múltiples niveles y monitoreo
riesgo bajo + cambio frecuente
→ pruebas rápidas enfocadas en comportamientoPara cada riesgo registra:
Dos solicitudes leen la misma disponibilidad y reservan las últimas unidades.
Un test secuencial no reproduce la carrera.
Distingue:
Incluye:
No copies producción sin controles de privacidad.
Un ambiente útil debe declarar diferencias respecto a producción.
igual o equivalente
→ versión de runtime
→ esquema
→ configuración crítica
→ topología relevante
posible diferencia
→ escala
→ proveedor sandbox
→ datos sintéticosUna prueba aprobada en un entorno sin latencia externa no demuestra el comportamiento distribuido real.
Alternativas:
Usa cada uno según la pregunta. Simular todo crea falsa confianza; depender siempre del proveedor vuelve inestable el pipeline.
Incluye:
La resiliencia solo existe si el mecanismo ha sido ejercitado.
Al fallar, una prueba debe mostrar:
Capturar una enorme cantidad de logs sin estructura no facilita diagnóstico.
Automatiza cuando la comprobación:
Mantén exploración humana cuando se necesita juicio, descubrimiento o percepción contextual.
Detecta tarde, cuesta diagnosticar y cubre pocas combinaciones.
Acopla las pruebas a refactors sin aumentar confianza.
La prueba termina verificando la expectativa del mock.
Muchos fallos reales no aparecen en ejecuciones lineales.
La cobertura señala código ejecutado, no riesgo demostrado.
El código nuevo puede funcionar mientras el cambio de datos rompe despliegue o recuperación.
Capacidad o riesgo:
Escenarios críticos:
Invariantes:
Niveles de prueba:
Datos:
Ambiente:
Dependencias:
Oráculo:
Evidencia:
Riesgo no cubierto:
Owner:Gestión de cambios usa esta trazabilidad para modificar requisitos, contratos y datos sin perder compatibilidad ni evidencia.