Consumer-Driven Contract Tests: Integrationen prüfen ohne gemeinsame Umgebung

Worum es geht

Ein Contract-Test prüft, ob zwei Seiten einer Integration sich über die Form ihres Austauschs einig sind, ohne beide gemeinsam laufen zu lassen. In der consumer-driven Variante schreibt der Consumer den Contract – die Pact-Dokumentation definiert ihn als die Seite, die die Anfrage auslöst oder die Nachricht liest: Jede Interaktion zeichnet eine erwartete Anfrage und eine minimale erwartete Antwort auf, nämlich die Teile der Antwort, die der Consumer tatsächlich nutzt. Der Consumer-Test läuft gegen einen aus dieser Beschreibung erzeugten Mock-Provider, und das Ergebnis ist eine Pact-Datei. Die Provider-Verifikation spielt jede Anfrage gegen den echten Provider ab und besteht, wenn die Antwort mindestens die beschriebenen Daten enthält. Provider-Zustände («Nutzer 123 existiert») richten Vorbedingungen ein, statt Aufrufe zu verketten. Fowlers Bliki beschreibt die allgemeine Form: Contract-Tests bestätigen, dass ein Test-Double weiterhin zum echten Dienst passt, und laufen im Rhythmus der Änderungen des externen Diensts, nicht im Rhythmus der Pipeline des Consumers.

Warum es wichtig ist

Umgebungen, die jeden Dienst starten, entdecken breaking Changes spät, werden gemeinsam genutzt und schlagen aus Gründen fehl, die nichts mit der getesteten Änderung zu tun haben. Contract-Tests verlagern die Erkennung in den eigenen Unit-Test-Lauf jedes Diensts und machen die Kopplung explizit: Ein Provider kann sehen, von welchen Feldern Consumer abhängen und welche sich frei ändern lassen. Der Pact Broker zeichnet auf, welche Consumer- und Provider-Versionen gegeneinander verifiziert wurden; der Befehl can-i-deploy prüft eine Version gegen die Versionen, die als in einer Umgebung deployt aufgezeichnet sind, und beendet sich mit einem Fehlercode, wenn eine Verifikation fehlt oder fehlgeschlagen ist.

So wird es angewendet

• Interaktionen aus dem echten Client-Code des Consumers erzeugen; nur die Felder beschreiben, die der Consumer liest, und Typ-Matcher verwenden, wo der exakte Wert nicht entscheidend ist.
• Interaktionen unabhängig voneinander halten; Vorbedingungen als Provider-Zustände ausdrücken, nie als Abfolge von Aufrufen.
• Pacts aus der Consumer-Pipeline veröffentlichen, in der Provider-Pipeline verifizieren, Deployments aufzeichnen und Releases über die Kompatibilitätsprüfung statt über einen gemeinsamen Staging-Lauf freigeben.
• Eine fehlgeschlagene Verifikation als Gespräch behandeln: Entweder bricht die Änderung des Providers einen Consumer, oder die Erwartung des Consumers war strenger, als er tatsächlich braucht.

Stolpersteine

Ein Contract, der die gesamte Antwort des Providers kopiert, ist eine zweite Kopie der API und bricht bei jeder Änderung. Contract-Tests prüfen Form und vereinbarte Semantik, nicht Geschäftsregeln, Performance oder Autorisierung. Der Contract ist nur so ehrlich wie der Consumer darüber, was er tatsächlich nutzt. Ohne einen Broker oder eine gleichwertige Aufzeichnung verifizierter Versionen geht die Matrix verloren, und Teams fallen zurück auf «alles gemeinsam laufen lassen». Nachrichtenbasierte Integrationen brauchen dieselbe Disziplin: Der Pact beschreibt dann die minimale Nachricht, die der Consumer verarbeiten kann.