Contract Testing

Contract Testing prüft die Vereinbarung zwischen zwei Services isoliert. Jede Seite wird gegen eine gemeinsame Beschreibung der Interaktionen getestet, den Contract (Vertrag), statt gegen den jeweils anderen, live laufenden Service. Ändert der Provider einen Feldnamen, auf den sich ein Consumer verlässt, schlägt ein Contract Test in der Pipeline des Providers fehl, bevor irgendetwas deployt wird. Bei Kosten und Aussagekraft liegt es zwischen Integrationstests und End-to-End-Tests.

So funktioniert Consumer-Driven Contract Testing

Die verbreitetste Form, bekannt geworden durch das Tool Pact, ist consumer-driven:

1. Der Consumer schreibt einen Test gegen einen Mock-Provider und legt fest, welche Requests er sendet und welche Teile der Response er tatsächlich nutzt. Zum Beispiel: GET /orders/42 liefert 200 mit einer Zahl id und einem String status.
2. Der Testlauf erzeugt eine Contract-Datei (einen „Pact“), die diese Interaktionen festhält.
3. Der Contract wird geteilt, meist über einen Broker-Service.
4. Der Provider verifiziert den Contract, indem er jeden aufgezeichneten Request gegen seine echte Implementierung abspielt und prüft, ob die Responses passen.
5. Vor dem Deployment prüft ein Team, ob die Version, die es gleich ausrollt, mit den Versionen der Gegenseite kompatibel ist, die bereits in dieser Umgebung laufen.

Da der Consumer nur die Felder auflistet, die er nutzt, kann der Provider frei Felder ergänzen oder alles ändern, wovon kein Consumer abhängt.

Abgrenzung zu verwandten Prüfungen

• Schema-Validierung prüft eine Response gegen das veröffentlichte Schema des Providers. Sie sagt Ihnen, dass der Provider zu seiner eigenen Dokumentation passt, nicht dass er noch die Bedürfnisse jedes Consumers erfüllt.
• Integrationstests rufen den echten Provider auf. Sie brauchen beide Services samt Abhängigkeiten und sind tendenziell langsamer und flakier.
• End-to-End-Tests beweisen, dass eine komplette User Journey funktioniert, sind aber ein langsamer und teurer Weg, um herauszufinden, dass ein Feld umbenannt wurde.

Provider-driven Contracts, bei denen der Provider eine OpenAPI-Spezifikation veröffentlicht und Consumer dagegen testen, sind eine Alternative, wenn der Provider nicht alle seine Consumer kennen oder sich mit ihnen abstimmen kann, etwa bei einer öffentlichen API.

Häufige Fehler

• Zu viel spezifizieren. Wer exakte Werte oder jedes Feld prüft, macht aus Contracts fragile Funktionstests. Verwenden Sie Type Matcher und nehmen Sie nur auf, was der Consumer liest.
• Geschäftslogik in Contracts testen. Contracts prüfen die Form der Kommunikation; fachliche Korrektheit gehört in die eigenen Tests des Providers.
• Provider States weglassen. „Order 42 existiert“ muss während der Verifikation auf Provider-Seite hergestellt werden, sonst schlägt die Verifikation aus dem falschen Grund fehl.