Respuesta
Parto de que en microservicios el riesgo principal está en las interfaces entre servicios y que los E2E completos son lentos, frágiles y caros de mantener. Por eso busco feedback rápido y aislado.
Capas
- Unitarias: la lógica de dominio de cada servicio. Son muchas y rápidas.
- Integración del componente: el servicio contra sus dependencias reales de infraestructura (base de datos, broker) levantadas con contenedores, por ejemplo Testcontainers. Los demás servicios se reemplazan con stubs.
- Contract testing: valida que productor y consumidor coincidan en el formato de las peticiones, las respuestas y los mensajes.
- E2E: pocos, solo para los flujos críticos de negocio, en un entorno integrado.
- En producción: smoke tests post-deploy, monitoreo sintético, canary y feature flags.
Contract testing consumer-driven (por ejemplo, Pact)
- El consumidor define en sus tests qué espera del proveedor, y eso genera un contrato.
- El contrato se publica en un broker.
- El proveedor lo verifica en su pipeline contra su implementación real.
- Antes de desplegar, una herramienta como can-i-deploy indica si las versiones son compatibles.
Así un cambio que rompe a un consumidor se detecta en el CI del proveedor, sin levantar todo el ecosistema. Esto no reemplaza a los tests funcionales del proveedor: el contrato valida la forma y las interacciones esperadas, no toda la lógica de negocio.
Complemento con tests no funcionales (carga, resiliencia ante timeouts y caídas de dependencias, seguridad de APIs) y con métricas de la estrategia: tiempo del pipeline, tasa de flaky y defectos escapados a producción.
Errores comunes
Basar todo en una suite E2E gigante o confundir el contract testing con la validación de un esquema OpenAPI hecha solo del lado del proveedor. También es un error omitir el testing en producción y la observabilidad como parte de la estrategia.
Redactado con el asistente Underc0de IA. Actualizado el 09/11/2026. ¿Ves un error? Contanos en el foro.