Contract testing verifica che due servizi concordino sulla loro API senza eseguirli insieme in un test di integrazione completo. In consumer-driven contracts (CDC), il consumatore definisce ciò di cui ha bisogno, e il provider verifica di poterlo fornire.
I test end-to-end completi su molti servizi sono lenti, instabili e difficili da eseguire ad ogni commit. I contract test rilevano i cambiamenti API interrompenti all'inizio, in isolamento.
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
});
La CI del provider riproduce questo e fallisce se non restituisce più quella struttura.
| Contract test | Integration test | |
|---|---|---|
| Servizi in esecuzione | Uno alla volta | Tutti insieme |
| Velocità | Veloce | Lento |
| Rileva | Rotture di contratto | Problemi di connessione reali |
I contract test ti danno la fiducia che un cambiamento al provider non romperà i consumatori, senza il costo e l'instabilità di avviare l'intero sistema.
Rendono il deployment indipendente sicuro: la pipeline di ogni team sa immediatamente se il suo cambio violerebbe un contratto da cui qualcuno dipende.