Contract Testing

Resumen

En microservicios, cada equipo evoluciona sus APIs de forma independiente. Un cambio en el proveedor —renombrar un campo, cambiar un tipo— puede romper al consumidor sin que nadie se entere hasta produccion. El contract testing resuelve esto: el consumidor define sus expectativas —"espero que GET /users/42 devuelva un objeto con name y email"— y el proveedor verifica que las cumple.

Pact es la herramienta mas conocida. Los contratos se comparten via un broker (Pact Broker) y ambos lados validan en CI. Si un cambio rompe el contrato, el pipeline falla antes del deploy.

Alcance y supuestos

Cubre contract testing, su relacion con integration testing y Pact. Asume familiaridad con microservicios.

Modelo mental

Un contrato legal entre dos empresas. Cada una puede cambiar sus procesos internos, pero mientras el contrato se cumpla —entregas en fecha, calidad pactada—, la otra no se ve afectada.

Uso práctico

• ✅ Microservicios con equipos independientes, APIs publicas con multiples consumidores.
• ❌ Monolitos: los tests de integracion cubren el mismo riesgo.

Ejemplo trabajado: contrato entre frontend y API

El equipo frontend define un contrato con Pact: espera que GET /users/42 devuelva status 200 con body conteniendo name e email. El equipo backend ejecuta el contrato en su CI. Si renombran name a fullName, el contrato falla antes del deploy.

Evidencia

• Pact es el estandar de facto. Spring Cloud Contract es una alternativa para el ecosistema JVM.