Was ein Vertrag enthalten sollte
Ein Verbraucher benötigt oft nur einen Teil einer Antwort. Ein Vertrag beschreibt beispielsweise benötigte Felder, Datentypen und zulässige Fehlerantworten. Wird ein optionales Feld ergänzt, muss das kein Problem sein. Wird ein Preisfeld umbenannt oder seine Einheit verändert, kann derselbe Aufruf fachlich falsch werden. Semantik ist deshalb ebenso wichtig wie ein passendes JSON-Schema.
Anbieter und Verbraucher gemeinsam prüfen
Beim verbrauchergetriebenen Ansatz formuliert der nutzende Dienst seine Erwartungen. Der Anbieter überprüft diese gegen seine Umsetzung. Ein gemeinsamer Vertragsstand macht sichtbar, welche Versionen zusammenpassen. Dafür braucht es Verantwortung: Veraltete Verträge und nicht mehr betriebene Verbraucher sollten nicht endlos jede Änderung blockieren.
Wo die Grenze liegt
Ein Contract Test zeigt nicht automatisch, dass Netzwerk, Identitäten und reale Datenbestände zusammen funktionieren. Auch ein Workflow über mehrere Dienste kann an Reihenfolge oder Zeitverhalten scheitern. Für ausgewählte Abläufe bleiben daher Integrationstests mit echter Kommunikation notwendig. Der Vorteil liegt darin, viele einfache Inkompatibilitäten schon vorher abzufangen.
Beispiel: Lieferstatus im Kundenportal
Das Portal erwartet eine Sendungskennung, einen bekannten Status und ein optionales Lieferdatum. Der Logistikdienst möchte neue Statuswerte einführen. Der Vertrag zeigt früh, dass das Portal unbekannte Werte bisher nicht behandelt. Eine kontrollierte Erweiterung des Verbrauchers vermeidet einen Fehler erst nach der produktiven Auslieferung.
Womit Sie sinnvoll beginnen können
- Verträge aus tatsächlichen Verbraucherbedürfnissen ableiten.
- Versionsfreigaben mit den geprüften Vertragsständen verknüpfen.
- Für wichtige Geschäftsabläufe weiterhin echte Integrationstests behalten.