Un despliegue reciente rompió tres microservicios a pesar de que todas las pruebas unitarias, de integración y las comprobaciones del servidor de mocks pasaron correctamente. El equipo cambió sus mocks de API por pruebas de contrato (contract testing). En seis meses, el número de contratos aumentó de tres a 47 y la tasa mensual de fallos de integración bajó de dos incidentes a cero.
Por qué los mocks no pueden protegerte
Un servidor de mocks solo imita la estructura que espera un consumidor; nunca comprueba que el proveedor realmente entregue esa estructura. Si un proveedor renombra un campo —por ejemplo, de name a display_name— el mock sigue devolviendo el payload antiguo, las pruebas del consumidor siguen en verde y el sistema en producción falla. El fallo en producción un martes a las 2 p. m. fue exactamente eso: el mock "mintió" sobre el contrato real.
Las pruebas de contrato cubren el vacío
Las pruebas de contrato obligan a las dos partes de una API a acordar una definición compartida antes de que cualquier código llegue a producción. Existen dos enfoques comunes:
- Contratos dirigidos por el consumidor (Consumer-driven contracts) – el servicio consumidor escribe las expectativas; el servicio proveedor las valida. Esto funciona bien para microservicios internos que evolucionan juntos.
- Contratos dirigidos por el proveedor (Provider-driven contracts) – el proveedor publica una especificación; los consumidores comprueban su código con ella. Este es el patrón habitual para las API públicas.
El primer enfoque generalmente evita integraciones rotas dentro de una arquitectura de microservicios.
Cómo funciona un contrato dirigido por el consumidor
- El consumidor escribe una prueba que describe exactamente lo que necesita del proveedor.
- Al ejecutar la prueba se genera un pact file —un documento JSON que registra esas expectativas.
- El proveedor ejecuta su servicio real contra el pact file en su pipeline de CI.
- Si el proveedor cambia un campo, la verificación falla y la compilación se bloquea.
Debido a que la verificación se ejecuta sobre el código real del proveedor, cualquier cambio disruptivo se detecta a tiempo, no después del despliegue.
Dónde encajan las pruebas de contrato en tu pirámide de pruebas
- Pruebas unitarias – rápidas, prueban la lógica aislada.
- Pruebas de contrato – velocidad media, confirman que los acuerdos de la API se mantienen.
- Pruebas de extremo a extremo (end-to-end) – lentas, ejecutan flujos de negocio completos.
Trata las pruebas de contrato como un puente entre la retroalimentación rápida de las pruebas unitarias y la amplia cobertura de las suites de extremo a extremo. Enfócate en los puntos de integración que fallan con más frecuencia y comienza con dos o tres endpoints críticos.
Una historia de adopción en el mundo real
El equipo que inspiró este artículo comenzó con tres contratos que cubrían sus llamadas más frágiles. Seis meses después, tenían 47 contratos que cubrían la mayor parte del tráfico entre servicios. Durante ese período, los incidentes de rotura de API disminuyeron de dos por mes a cero.
Cuándo las pruebas de contrato pueden no valer la pena
- Eres un desarrollador independiente que mantiene todos los servicios en un único repositorio.
- La API es excepcionalmente estable y no ha cambiado en años.
- Estás construyendo un prototipo desechable que se descartará pronto.
En esos escenarios, la sobrecarga de mantener los contratos puede superar el beneficio.
Posibles desventajas y cómo mitigarlas
- Mantén los contratos versionados junto al código que describen.
- Automatiza la verificación en cada ejecución de CI para evitar contratos obsoletos.
- Revisa los cambios en los contratos en los pull requests para detectar roturas accidentales.
Conclusión
Si todavía dependes de mocks manuales para convencerte de que tus servicios pueden comunicarse, estás apostando por una falsa promesa. Las pruebas de contrato convierten esa apuesta en un acuerdo verificable, detectando cambios disruptivos antes de que lleguen a producción y, como muestran las cifras del equipo, pueden eliminar por completo los fallos de integración.