Consumer-Driven Contract Testing
Consumer-Driven Contract Testing lässt Konsumenten ausführbare Erwartungen veröffentlichen, die der Anbieter in seiner Build-Pipeline gegen die aktuelle Implementierung verifiziert.
- KonsumentenerwartungBeschreibt minimal die tatsächlich genutzte Interaktion.
- Provider-VerifikationFührt alle veröffentlichten Erwartungen gegen die Anbieterimplementierung aus.
- VersionsmatrixVerbindet Contract, Konsument, Provider und Umgebung.
Einordnung
Warum das wichtig ist
Der Ansatz prüft beobachtbare Interaktionen zwischen bekannten Teilnehmern; er ergänzt Anbieter-Schema, fachliche Integrationstests und Laufzeitbeobachtung.
Die verteilte Ausbaustufe im Shop-Szenario ist hypothetisch; der aktuelle Shop bleibt ein modularer Monolith mit sieben Modulen und gemeinsamer Datenbank.
Consumer-Driven Contract Testing: Entscheidungsgrenzen
Der aktuelle Shop bleibt ein modularer Monolith mit sieben Modulen. Bestellung konsumiert den internen Vertrag von Zahlung für Autorisierungsstatus und Ablehnungsgrund. Das Bestellungsteam veröffentlicht einen Contract mit Erfolgs- und Ablehnungsbeispiel; Zahlung verifiziert ihn in der Pipeline gegen jede Änderung. Für eine hypothetische spätere Diensttrennung werden Contract, Provider-Version und Deploy-Umgebung gemeinsam veröffentlicht. Das Team bricht absichtlich ein optional gewordenes Feld und prüft, ob nur tatsächlich genutzte Erwartungen eine Freigabe blockieren.
So liest du das Bild
- Konsumentenerwartung Relevante Felder und Fehler
- Provider-Verifikation Pipeline-Gate
- Versionsmatrix Freigabe mit konkreten Versionen
| Vergleich | Aspekt | Tragfähiger Einsatz | Grenze |
|---|---|---|---|
| Schema-Validierung | Prüft gesamte Form des Anbietercontracts | Breite syntaktische Abdeckung | Belegt keine reale Konsumentennutzung |
| Consumer Contract | Prüft genutzte Beispiele und Fehler | Frühes Kompatibilitätssignal | Nur bekannte veröffentlichte Erwartungen |
| End-to-End-Test | Prüft laufende Integration | Hohe Realitätsnähe | Langsamer und schwerer zu isolieren |
Nutzen & Grenzen
Hilft, wenn
- Breite syntaktische Abdeckung
- Frühes Kompatibilitätssignal
- Hohe Realitätsnähe
Grenzen
- Belegt keine reale Konsumentennutzung
- Nur bekannte veröffentlichte Erwartungen
- Langsamer und schwerer zu isolieren
In der Praxis
- Wähle eine reale Zahlungsschnittstelle und notiere nur die Felder, Statuscodes und Fehlerformen, die Bestellung tatsächlich auswertet. Erzeuge daraus einen minimalen Erfolgs- und Ablehnungscontract.
- Ändere im Anbieter ein genutztes Feld inkompatibel und ein ungenutztes Feld kompatibel. Führe die Provider-Verifikation aus und prüfe, dass nur die echte Konsumentenerwartung die Freigabe blockiert.
- Baue eine Versionsmatrix aus Contract, Konsument, Provider und Zielumgebung. Simuliere einen alten Konsumenten und entscheide anhand veröffentlichter Verifikationen, welche Provider-Version sicher ausgerollt werden kann.
Ausführliche Erklärung lesen
Ein Konsument zeichnet minimale relevante Anfrage-Antwort-Beispiele als Contract auf. Der Anbieter führt diese Erwartungen gegen eine isoliert gestartete Version aus und veröffentlicht das Verifikationsergebnis.
Die Freigabeentscheidung muss konkrete Konsumenten- und Anbieterversionen verbinden. Übergenaue Beispiele koppeln an irrelevante Felder; fehlende negative Fälle übersehen Fehlersemantik und fachliche Bedeutung.
API-Verträge beschreiben den vollständigen Anbieterrahmen. API-Versionierung ordnet kompatible Evolution und parallele Vertragsstände.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Was ist die Kernaufgabe von Consumer-Driven Contract Testing?
Lösung mit Begründung ansehen
Consumer-Driven Contract Testing lässt Konsumenten ausführbare Erwartungen veröffentlichen, die der Anbieter in seiner Build-Pipeline gegen die aktuelle Implementierung verifiziert.
AnwendenAuf eine neue Lage übertragen
Welche Annahme ist im Shop hypothetisch?
Lösung mit Begründung ansehen
Bestellung konsumiert den internen Vertrag von Zahlung für Autorisierungsstatus und Ablehnungsgrund. Das Bestellungsteam veröffentlicht einen Contract mit Erfolgs- und Ablehnungsbeispiel; Zahlung verifiziert ihn in der Pipeline gegen jede Änderung.
BewertenEine Alternative abwägen
Welche drei Punkte müssen vor einer Einführung belegt sein?
Lösung mit Begründung ansehen
Konsumentenerwartung, Provider-Verifikation, Versionsmatrix.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Pact · How Pact works (öffnet in neuem Tab)Fachquelle zu Consumer-Driven Contract Testing.
- Martin Fowler · Consumer-Driven Contracts (öffnet in neuem Tab)Fachquelle zu Consumer-Driven Contract Testing.
- microservices.io · Consumer-side contract test (öffnet in neuem Tab)Fachquelle zu Consumer-Driven Contract Testing.