Wenn ein Microservice eine API ändert, reicht oft schon ein umbenanntes Feld oder ein anderer HTTP-Status, um eine funktionierende Anwendung zu brechen. Contract Testing prüft genau diese Kommunikation zwischen Consumer und Provider, bevor die Änderung in Produktion landet. Ich zeige, wie die Methode funktioniert, wann sich ihr Einsatz lohnt, welche Werkzeuge infrage kommen und wo ihre Grenzen liegen.
Vertragstests machen Schnittstellenänderungen früh sichtbar
- Prüfziel: Consumer und Provider halten dieselben Erwartungen an Requests und Responses ein.
- Typischer Ablauf: Der Consumer beschreibt eine Interaktion, der Provider verifiziert sie in seiner CI-Pipeline.
- Besonders geeignet: Microservices, REST-APIs, Messaging-Systeme und unabhängig deploybare Teams.
- Wichtige Grenze: Vertragstests ersetzen weder fachliche Tests noch vollständige End-to-End-Szenarien.
- Praktischer Start: Mit einem kritischen Endpoint und zwei bis drei realistischen Fällen beginnen.
Warum Schnittstellen trotz guter Tests brechen
Ein Service kann seine eigenen Unit- und Integrationstests vollständig bestehen und trotzdem einen anderen Service unbrauchbar machen. Der Grund liegt häufig nicht in der internen Logik, sondern in einer abweichenden Annahme über die Schnittstelle.
Ein Frontend erwartet beispielsweise das Feld customerName, während der zuständige Service nach einer Überarbeitung nur noch name liefert. Beide Teams sehen zunächst grüne Testberichte. Erst die echte Verbindung zeigt, dass die gemeinsame Vereinbarung nicht mehr erfüllt wird.
Ein Vertragstest beschreibt diese Vereinbarung als überprüfbare Interaktion. Dazu gehören etwa die HTTP-Methode, der Pfad, bestimmte Header, Pflichtfelder, Datentypen und die erwartete Antwort. Bei Messaging-Systemen können auch Nachrichtenformat, Routing-Key und Pflichtattribute Teil des Vertrags sein.
Ich sehe den größten Nutzen nicht darin, möglichst viele Tests zu schreiben. Entscheidend ist, die wenigen Erwartungen festzuhalten, deren Verletzung einen anderen Service tatsächlich aus dem Takt bringt.
So funktioniert ein Vertragstest im Alltag
Die beiden Rollen sind schnell erklärt. Der Consumer nutzt eine Schnittstelle, etwa ein Checkout-Service, der Kundendaten abruft. Der Provider stellt diese Schnittstelle bereit, zum Beispiel ein Kundenservice mit einer REST-API.
Der Consumer formuliert eine konkrete Erwartung. Für die Anfrage GET /customers/42 soll der Provider den Status 200 zurückgeben und ein JSON-Objekt mit einer Kunden-ID und einer E-Mail-Adresse liefern. Diese Interaktion wird zunächst gegen einen Mock oder Stub geprüft, also gegen eine kontrollierte Testumgebung.
Aus dem Test entsteht ein maschinenlesbarer Vertrag. Der Provider führt denselben Vertrag später gegen seine laufende Anwendung aus. Damit wird nicht nur geprüft, ob die Antwort formal korrekt aussieht, sondern auch, ob der Consumer seine Anfrage so stellt, wie der Provider sie erwartet.
{
"request": {
"method": "GET",
"path": "/customers/42"
},
"response": {
"status": 200,
"body": {
"id": 42,
"email": "kunde@example.de"
}
}
}In einem typischen Ablauf ergeben sich fünf Schritte:
- Der Consumer-Test beschreibt eine tatsächlich benötigte Interaktion.
- Das Werkzeug speichert daraus einen Vertrag.
- Der Vertrag wird versioniert oder in einem Broker veröffentlicht.
- Die Provider-Pipeline ruft den Vertrag ab und spielt die Anfrage gegen den Service aus.
- Das Ergebnis entscheidet, ob die Version als kompatibel gilt.
Bei einer asynchronen Kommunikation läuft das Prinzip ähnlich. Statt Request und Response wird beispielsweise geprüft, ob eine veröffentlichte OrderCreated-Nachricht genau die Felder enthält, die ein nachgelagerter Service benötigt. Der Unterschied liegt im Transport, nicht in der Grundidee.
Consumer-driven Contracts und andere Varianten
In vielen Microservice-Landschaften setzen Teams auf Consumer-Driven Contracts. Dabei beschreibt der Consumer seine realen Anforderungen, statt dass ein Provider vorsorglich eine riesige Spezifikation für alle denkbaren Fälle erstellt.
Das hat einen praktischen Vorteil. Der Provider muss nur das stabil halten, was tatsächlich genutzt wird. Ein zusätzliches Feld kann oft problemlos hinzukommen, während das Entfernen eines benötigten Feldes oder eine Änderung des Datentyps als kompatibilitätsbrechende Änderung auffällt.
Daneben gibt es providergetriebene Ansätze. Hier steht eine zentrale Schnittstellendefinition im Mittelpunkt, etwa ein OpenAPI-Dokument oder ein DSL-Vertrag von Spring Cloud Contract. Dieser Ansatz passt gut zu Organisationen, in denen ein Plattformteam APIs zentral entwirft und mehrere Konsumenten nach einer gemeinsamen Spezifikation arbeiten.
| Ansatz | Wer beschreibt die Erwartung | Stärke | Typische Grenze |
|---|---|---|---|
| Consumer-driven | Der nutzende Service | Prüft reale Bedürfnisse einzelner Konsumenten | Viele Konsumenten können die Pflege aufwendiger machen |
| Provider-driven | Der bereitstellende Service | Zentrale, einheitliche API-Vorgaben | Die Spezifikation kann an echten Nutzungsfällen vorbeigehen |
| Schema-Validierung | Ein gemeinsames Schema | Gut für Struktur, Typen und Dokumentation | Beweist nicht automatisch, dass beide Seiten dieselbe Interaktion erwarten |
Ein OpenAPI-Schema und ein Vertragstest sind deshalb keine direkten Konkurrenten. Das Schema beschreibt meist, was eine API grundsätzlich erlaubt. Der Vertragstest prüft, was ein bestimmter Consumer wirklich verwendet. In einer reifen Architektur ergänzen sich beide Ebenen.
Wie ich die Methode in eine CI-Pipeline integriere
Ich würde nicht mit der gesamten Service-Landschaft anfangen. Ein besserer Einstieg ist eine geschäftlich wichtige Verbindung, bei der Änderungen regelmäßig Abstimmungen oder manuelle Tests auslösen. Das kann die Verbindung zwischen Warenkorb und Bestellservice oder zwischen einem Portal und einer Zahlungs-API sein.
Mit realistischen Interaktionen beginnen
Der erste Vertrag sollte nicht jede mögliche Antwort abbilden. Zwei bis drei Fälle reichen oft aus, etwa eine erfolgreiche Abfrage, ein unbekanntes Objekt und ein Validierungsfehler. Entscheidend ist, dass die Fälle aus dem echten Client-Code stammen und nicht aus einer theoretischen Wunschliste.
Passende Werkzeuge auswählen
Pact ist ein verbreiteter codebasierter Ansatz für Consumer-Driven Contracts und unterstützt unter anderem HTTP- sowie Messaging-Szenarien. Für Spring-Ökosysteme ist Spring Cloud Contract interessant, weil Verträge beispielsweise mit DSL oder YAML definiert und daraus Tests sowie Stubs erzeugt werden können.
Bei der Auswahl zählt weniger der Markenname als die Integration in die vorhandene Umgebung. Ich prüfe zuerst, ob die Sprache des Consumers und Providers unterstützt wird, wie Verträge versioniert werden und ob die CI-Pipeline verständliche Ergebnisse liefert.
Lesen Sie auch: ATDD verständlich erklärt - Akzeptanztests vor dem Coding
Kompatibilität vor dem Deployment prüfen
Der Consumer veröffentlicht seinen Vertrag zusammen mit einer eindeutigen Version. Der Provider verifiziert ihn gegen seinen Build. Ein Deployment darf nur dann freigegeben werden, wenn die Kombination aus Consumer- und Provider-Version als kompatibel gilt.
Ein zentraler Contract Broker kann dabei Verträge, Versionen und Verifikationsergebnisse verwalten. Er ist besonders hilfreich, sobald mehrere Teams beteiligt sind. Bei nur zwei eng gekoppelten Services genügt für den Anfang oft ein gemeinsames Repository oder ein kontrollierter Artefakt-Speicher.
Für die tägliche Arbeit ist eine klare Fehlermeldung wichtiger als ein schönes Dashboard. Ein fehlender JSON-Schlüssel sollte direkt zeigen, welcher Consumer welche Provider-Antwort erwartet und in welchem Commit die Abweichung entstanden ist.
Was Vertragstests leisten und was nicht
Die Methode prüft die technische Kompatibilität einer Kommunikation. Sie beantwortet jedoch nicht, ob eine Bestellung fachlich korrekt berechnet wird, ob eine Datenbanktransaktion sicher ist oder ob ein kompletter Benutzerprozess sinnvoll funktioniert.
| Testart | Hauptfrage | Beispiel |
|---|---|---|
| Unit-Test | Funktioniert eine isolierte Einheit? | Berechnet der Rabattservice den Preis richtig? |
| Vertragstest | Verstehen sich zwei Services an ihrer Schnittstelle? | Erwartet der Client dieselben Felder wie die API? |
| Integrationstest | Funktionieren mehrere technische Komponenten zusammen? | Schreibt der Service korrekt in die Datenbank? |
| End-to-End-Test | Funktioniert ein kompletter Geschäftsprozess? | Kann ein Nutzer eine Bestellung abschließen? |
Ein häufiger Fehler ist, Vertragstests in verkappte Funktionstests des Providers zu verwandeln. Der Consumer muss nicht prüfen, ob der Provider intern die richtige Datenbankabfrage verwendet. Relevant ist nur, ob die vereinbarte Schnittstelle für den konkreten Anwendungsfall funktioniert.
Ebenso problematisch sind übermäßig strenge Erwartungen. Wenn ein Consumer jedes zusätzliche Feld in einer Antwort ablehnt, wird jede harmlose Erweiterung zum Build-Fehler. Ich definiere deshalb nur das als verpflichtend, was der Consumer wirklich benötigt, und nutze flexible Matcher für Werte wie IDs, Zeitstempel oder zufällig erzeugte Tokens.
Typische Grenzen und die Bedingungen für Erfolg
Vertragstests funktionieren am besten, wenn Teams ihre Schnittstellen wirklich versionieren und Änderungen sichtbar machen. Ohne klare Zuständigkeiten entstehen schnell veraltete Verträge, die niemand mehr pflegt. Ein grüner Test ist dann zwar technisch korrekt, aber für die aktuelle Systemlandschaft wertlos.
Auch die Zustandsvorbereitung darf nicht unterschätzt werden. Wenn der Provider einen Vertrag nur mit einer ganz bestimmten Datenbankkonfiguration erfüllt, muss die Testumgebung diesen Zustand reproduzierbar herstellen. Sonst schlägt die Pipeline zufällig fehl und verliert das Vertrauen der Entwickler.
Bei öffentlichen APIs mit unbekannten Konsumenten ist ein rein Consumer-getriebener Ansatz schwieriger. Dort braucht es zusätzlich stabile Regeln für Abwärtskompatibilität, dokumentierte Deprecation-Fristen und gegebenenfalls Schema- oder Spezifikationstests.
Die Methode spart vor allem Zeit bei Änderungen zwischen unabhängig deploybaren Services. Für ein kleines Monolith-Modul mit gemeinsamem Release-Zyklus kann der zusätzliche Pflegeaufwand größer sein als der Nutzen. Ich würde sie dort einsetzen, wo eine Schnittstelle von mehreren Teams oder Releases abhängt.
Der sinnvollste erste Vertrag für dein Team
Wähle eine Verbindung, deren Ausfall sofort sichtbar wäre, und dokumentiere zunächst nur eine erfolgreiche Interaktion sowie einen wichtigen Fehlerfall. Prüfe danach, ob der Test tatsächlich eine Lücke zwischen Consumer und Provider entdeckt, statt lediglich bereits bekannte Logik zu wiederholen.
Wenn die ersten Verträge stabil laufen, gehören sie in die normale CI-Pipeline und in den Review-Prozess. So wird die Schnittstelle nicht zu einer losen Dokumentation, sondern zu einer automatisch überprüften Vereinbarung, die beide Teams bei jeder relevanten Änderung begleitet.
Mein wichtigster Rat lautet deshalb, klein anzufangen und die Erwartungen bewusst knapp zu halten. Gute Vertragstests geben Teams nicht mehr Bürokratie, sondern eine belastbare Antwort auf die entscheidende Frage: Kann ich diesen Service ändern, ohne einen anderen unbemerkt zu beschädigen?
