Testagem de contrato verifica que dois serviços concordam com sua API sem executá-los juntos em um teste de integração completo. Em contratos orientados pelo consumidor (consumer-driven contracts - CDC), o consumidor define o que precisa, e o provedor verifica que consegue entregar.
Testes end-to-end completos entre muitos serviços são lentos, frágeis e difíceis de executar a cada commit. Testes de contrato pegam mudanças de API que quebram cedo, isoladamente.
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
});
O CI do provedor executa isso novamente e falha se não retornar mais essa forma.
| Teste de contrato | Teste de integração | |
|---|---|---|
| Serviços em execução | Um de cada vez | Todos juntos |
| Velocidade | Rápido | Lento |
| Detecta | Quebras de contrato | Problemas reais de conexão |
Testes de contrato lhe dão confiança de que uma mudança de provedor não quebrará consumidores, sem o custo e a fragilidade de ativar todo o sistema.
Eles tornam a implantação independente segura: o pipeline de cada equipe sabe imediatamente se sua mudança violaria um contrato do qual alguém depende.