Contract testing verifica que dos servicios estén de acuerdo en su API sin ejecutarlos juntos en una prueba de integración completa. En consumer-driven contracts (CDC), el consumidor define qué necesita, y el proveedor verifica que pueda entregarlo.
Las pruebas end-to-end completas en muchos servicios son lentas, inestables y difíciles de ejecutar en cada commit. Las pruebas de contrato detectan cambios de API que rompen la compatibilidad temprano, en aislamiento.
1. Consumer writes expectations ─▶ generates a CONTRACT (Pact file)
2. Contract published to a broker
3. Provider runs the contract against itself in its own pipeline
4. Provider build FAILS if it would break the consumer
// consumer declares exactly what it expects from the provider
provider.given('order 42 exists')
.uponReceiving('a request for order 42')
.withRequest({ method: 'GET', path: '/orders/42' })
.willRespondWith({
status: 200,
body: { id: '42', total: 99.5 } // the shape the consumer relies on
});
El CI del proveedor reproduce esto y falla si ya no devuelve esa estructura.
| Contract test | Integration test | |
|---|---|---|
| Servicios en ejecución | Uno a la vez | Todos juntos |
| Velocidad | Rápido | Lento |
| Detecta | Ruptura de contrato | Problemas de conexión reales |
Las pruebas de contrato te dan confianza en que un cambio del proveedor no romperá a los consumidores, sin el costo e inestabilidad de iniciar todo el sistema.
Hacen que el despliegue independiente sea seguro: el pipeline de cada equipo sabe inmediatamente si su cambio violaría un contrato del que alguien depende.