Software Architecture
Explica cómo diseñar testabilidad y una estrategia de pruebas basada en riesgos para reglas, contratos, persistencia, concurrencia, resiliencia y arquitectura.
La testabilidad no es una propiedad exclusiva del código de pruebas. Es una cualidad arquitectónica: el sistema debe permitir controlar entradas, observar resultados y comprobar garantías sin depender siempre del entorno completo ni ocultar fallos detrás de mocks.
Una estrategia de pruebas arquitectónicas busca evidencia sobre distintos riesgos.
reglas locales
→ pruebas unitarias
integración con mecanismos reales
→ pruebas de integración
límites entre componentes
→ contract tests
journeys críticos
→ end-to-end
atributos de calidad
→ carga, resiliencia, seguridad y recuperación
reglas estructurales
→ fitness functions y pruebas de arquitecturaNo existe una única pirámide válida para todos los sistemas. La mezcla depende del dominio, los fallos costosos y la topología. Un sistema de pagos necesita más evidencia sobre idempotencia y reconciliación que una landing page. Un monolito modular necesita pruebas de límites internos aunque no use red.
Sin testabilidad, el equipo descubre errores tarde y no puede comprobar decisiones importantes de manera repetible.
Ejemplos:
La testabilidad reduce la distancia entre una afirmación y su evidencia.
Antes de elegir una herramienta, formula:
riesgo: vender más stock del disponible
frontera: dominio + transacción de base de datos
prueba: solicitudes concurrentes sobre la última unidad
resultado: una reserva exitosa, las demás rechazadasUna prueba unitaria del método decreaseStock no demuestra que la persistencia proteja concurrencia. Una prueba end-to-end completa puede demostrarlo, pero quizá sea lenta y difícil de diagnosticar. La estrategia correcta combina pruebas en la frontera donde vive el riesgo.
Las reglas de dominio deben poder ejecutarse sin servidor HTTP, broker o proveedor externo.
class ConfirmOrder {
constructor(
private readonly orders: OrderRepository,
private readonly inventory: InventoryPort,
private readonly clock: Clock,
) {}
async execute(input: ConfirmOrderInput) {
const order = await this.orders.get(input.businessId, input.orderId);
order.confirm(this.clock.now());
await this.inventory.reserve(order.items);
await this.orders.save(order);
}
}El caso de uso recibe dependencias explícitas. Una prueba puede usar fakes para explorar reglas; las pruebas de adaptadores comprueban base de datos e integraciones reales.
La abstracción se justifica porque tiempo, persistencia e inventario son fronteras con comportamiento variable. No es necesario crear interfaces para funciones puras que no necesitan sustitución.
Tiempo, UUID, aleatoriedad, concurrencia y red producen resultados difíciles de repetir.
interface Clock {
now(): Date;
}
class FixedClock implements Clock {
constructor(private readonly value: Date) {}
now() { return this.value; }
}Esto permite probar expiraciones exactamente, sin modificar el reloj global ni esperar.
Una operación debe producir algo verificable:
El test no debería inspeccionar variables privadas para descubrir si funcionó. Debe observar el contrato relevante.
Bases, brokers y servicios emulados deben iniciarse con configuración conocida. Datos y migraciones forman parte del entorno.
Un test que pasa solo en el portátil de una persona no ofrece evidencia confiable.
Aíslan reglas, decisiones y transformaciones.
Son útiles para:
Ejemplo:
it("rechaza una devolución superior al monto pagado", () => {
const sale = Sale.paid({ total: 100_000 });
expect(() => sale.refund({ amount: 120_000 }))
.toThrow(RefundExceedsPaymentError);
});La prueba comprueba una regla sin infraestructura. No demuestra transacciones, autorización ni persistencia.
Mockear cada colaboración hace que las pruebas reproduzcan el código en lugar del comportamiento. Un refactor rompe tests aunque el contrato no cambie.
Prefiere:
Comprueban colaboración con mecanismos reales:
Ejemplo para inventario:
Esta prueba necesita el motor real, porque un fake en memoria no reproduce aislamiento, locks o sintaxis.
Un contrato incluye más que un schema JSON. También contiene:
El proveedor demuestra que implementa el contrato publicado.
Los consumidores expresan las partes que utilizan y el proveedor verifica que no las rompe.
Los contract tests reducen la necesidad de desplegar todo el sistema para detectar incompatibilidad. No demuestran comportamiento completo del negocio ni disponibilidad de red.
Ejecutan un journey a través de interfaces reales.
Úsalas para pocos flujos de alto valor:
Son costosas porque combinan muchos componentes. Cuando fallan, la causa puede ser ambigua. No deben ser la única defensa.
Una buena prueba end-to-end:
Verifican propiedades estructurales.
Ejemplos:
regla declarada
→ análisis automático
→ fallo en CI
→ corrección antes del mergeEstas pruebas convierten intención en gobierno. No pueden detectar si un límite está mal elegido; solo si el código respeta la regla definida.
Un documento que dice “tenemos backups” no demuestra recuperabilidad. Solo una restauración comprobada aporta evidencia.
Riesgos:
Estrategia:
La combinación demuestra más que cualquier prueba aislada.
Los datos deben representar casos relevantes:
Evita fixtures gigantes sin intención. Un builder puede expresar únicamente lo relevante:
const sale = aSale()
.forBusiness("business-a")
.paidWithTotal(100_000)
.build();La producción también contiene datos inesperados. Las migraciones y parsers necesitan pruebas con muestras reales anonimizadas o generadas a partir de sus características.
Dormir dos segundos no garantiza que un proceso termine y vuelve lenta la suite.
Prefiere:
El timeout debe explicar qué condición no se alcanzó.
La producción aporta condiciones imposibles de reproducir por completo.
Mecanismos:
“Testear en producción” no significa desplegar sin pruebas. Añade evidencia gradual y límites de impacto.
Para cada capacidad crítica crea una matriz:
| Riesgo | Evidencia | Frontera | Frecuencia |
|---|---|---|---|
| Sobreventa | Prueba concurrente | DB + caso de uso | CI |
| Contrato incompatible | Contract test | API/evento | CI |
| Fuga entre tenants | Matriz negativa | API + persistencia | CI |
| Restore inviable | Simulacro | Operación | Periódica |
Esto evita medir cobertura de líneas como si representara confianza completa.
Una línea ejecutada puede no tener assertions relevantes. Relaciona pruebas con riesgos.
Tests acoplados a llamadas internas impiden refactor. Observa contratos y resultados.
Un repositorio falso no prueba SQL, constraints ni transacciones.
Son lentas, frágiles y difíciles de diagnosticar. Distribuye evidencia.
El camino feliz no demuestra comportamiento ante timeouts, duplicados o concurrencia.
Tests inestables se ignoran. Trata flakiness como defecto, asigna ownership y elimina causas.
Fitness functions y gobierno automatizado convierte las restricciones arquitectónicas más importantes en controles continuos dentro del flujo de entrega.