Contract Testing überprüft, dass zwei Services sich auf ihre API einigen, ohne sie zusammen in einem vollständigen Integrationtest auszuführen. Bei Consumer-Driven Contracts (CDC) definiert der Consumer, was er benötigt, und der Provider überprüft, dass er es liefern kann.
End-to-End-Tests über viele Services hinweg sind langsam, anfällig für Ausfälle und schwer auf jedem Commit auszuführen. Contract Tests erkennen Breaking API-Änderungen frühzeitig und isoliert.
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
});
Das CI des Providers spielt dies ab und schlägt fehl, wenn es diese Form nicht mehr zurückgibt.
| Contract Test | Integrationstest | |
|---|---|---|
| Services laufen | Einzeln | Alle zusammen |
| Geschwindigkeit | Schnell | Langsam |
| Erfasst | Contract-Breaks | Echte Verdrahtungsprobleme |
Contract Tests geben dir Vertrauen, dass eine Provider-Änderung Consumer nicht bricht, ohne die Kosten und Anfälligkeit, das gesamte System hochzufahren.
Sie ermöglichen unabhängige Deployments: Die Pipeline jedes Teams weiß sofort, ob seine Änderung einen Contract verletzten würde, auf den jemand angewiesen ist.