Was Contract Testing prüft
Dass beide Seiten dieselbe Struktur erwarten. Feldnamen, Typen, Pflichtfelder und optionale Felder, Statuscodes. Entfernt ein Producer ein Feld, auf das ein Consumer angewiesen ist, schlägt Contract Testing zur Build-Zeit fehl statt um drei Uhr nachts.
In einem System mit vielen Services und unabhängigen Deployments ist das ein echter Gewinn – und deutlich günstiger als End-to-End-Integrationsumgebungen.
Was es bewusst nicht prüft
Ob der Wert stimmt. Eine strukturell korrekte Antwort mit der falschen Summe erfüllt jeden Contract.
Ob der Ablauf funktioniert. Jeder einzelne Aufruf kann seinen Contract erfüllen, während die Abfolge ein unsinniges Ergebnis liefert.
Was Nutzende sehen. Bei Contracts geht es darum, wie Services mit Services sprechen. Das Produkt hat dabei niemand geöffnet.
Nichts davon ist ein Vorwurf. Ein Contract Test, der Werte prüft, wäre an Daten gekoppelt und würde ständig fehlschlagen – genau das soll Contract Testing vermeiden. Die enge Fokussierung ist der eigentliche Punkt.
Das Fehlermuster, auf das Sie achten sollten
Ein Team führt Contract Testing ein, die Integrationsfehler hören auf, das Vertrauen wächst. Ein halbes Jahr später geht in der Produktion etwas kaputt, das jeden Contract Test bestanden hat: Die Struktur stimmte, das Verhalten nicht. Die übliche Schlussfolgerung lautet, Contract Testing habe versagt – und das ist die falsche Schlussfolgerung.
Contract Testing hat seine Aufgabe erfüllt. Die Lücke bestand darin, dass niemand das Verhalten geprüft hat, und der Erfolg der Contract-Ebene hat diese Lücke schwerer sichtbar gemacht.
Was daneben gehört
Funktionale Verifizierung gegen die laufenden Services: Liefert die Abfolge der Aufrufe das richtige Ergebnis, verhalten sich Fehlerpfade wie vorgesehen, greift die Autorisierung. Das ist eine andere Ebene, und sie beantwortet die Fragen, an die Contracts nicht heranreichen.
Diese Prüfungen müssen mit Sessions, zwischen Aufrufen erfassten Werten, Reihenfolge und Cleanup umgehen können – all das behandelt die Dokumentation zum API-Testing.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Wenn Sie lieber nichts installieren möchten: Das Dashboard leistet dasselbe. Alles Weitere, was die Kommandozeile kann, finden Sie im CLI-Repository.
Consumer-driven – und warum es meistens gewinnt
Die beiden Ansätze unterscheiden sich darin, wer den Contract schreibt, und der Unterschied zeigt sich nicht sofort, sondern ein Jahr später.
Producer-driven Contracts halten fest, was der Service anbieten will. Das ist nützlich und fällt meist großzügig aus: Der Contract beschreibt die vollständige Antwort, inklusive Feldern, die niemand nutzt. Breaking Changes an ungenutzten Feldern lassen dann den Build scheitern, Teams beginnen, Contract-Fehler zu ignorieren – und der Zweck ist dahin.
Consumer-driven Contracts halten fest, was jeder Consumer tatsächlich liest. Der Contract ist kleiner, die Fehlschläge sind echt, und es entsteht ein wirklich nützliches Nebenprodukt: eine präzise Karte, welche Felder für wen relevant sind. Genau diese Karte erlaubt es einem Producer, etwas guten Gewissens abzukündigen – und das ist es, was alle eigentlich wollten.
Wo beides jeweils läuft
Contract Tests zur Build-Zeit, schnell und bei jedem Commit, denn ihr ganzer Wert liegt darin, Struktur-Drift vor der Integration zu erkennen. Verhaltensprüfung gegen eine deployte Umgebung, bei jedem Pull Request.
Der Auslöser zählt mehr als der Mechanismus. Koppeln Sie ihn an Ihr Deployment-Ereignis, wird jede Änderung geprüft, ohne dass jemand das eigens entscheiden muss; die GitHub App übernimmt das aus dem Dashboard heraus, und ein GitHub Actions Schritt erledigt es aus Ihrem Workflow heraus.
Welche Fragen TestSprite beantwortet und Contracts nicht
Ob die Werte stimmen und ob die Abfolge das richtige Ergebnis liefert. TestSprite spricht die laufenden Services über ihre Schnittstellen an, sodass auch eine Antwort auffällt, die jeden Contract erfüllt und die falsche Summe enthält.
Mehrstufige Abläufe sind die konkrete Lücke. Integration Tests verketten Aufrufe, bei denen eine Antwort die nächste speist, und Dependency Chains leiten aus dem, was jeder Testfall benötigt und erzeugt, eine sichere Reihenfolge ab. Auto-Authentication hält Sessions über einen gesamten Lauf hinweg aktiv, Dynamic Variables transportieren Werte zwischen Aufrufen, Dependency Chains leiten die Ausführungsreihenfolge aus dem ab, was jeder Testfall benötigt und erzeugt, und Auto-Cleanup entfernt genau das, was der Lauf angelegt hat.
Am Ende stehen zwei Ebenen, die sich nicht überschneiden: Contracts, die Struktur-Drift zur Build-Zeit abfangen, günstig und bei jedem Commit, und die Verhaltensprüfung, die genau die Korrektheitsfragen abdeckt, für die Contracts bewusst blind sind.
Macht TestSprite Contract Testing?
Nein. TestSprite prüft Verhalten gegen laufende Services. Contract Testing ist ein anderes Instrument, und beide ergänzen einander.
Reicht Contract Testing für Microservices aus?
Für Struktur-Drift zwischen Services ist es die richtige Antwort, und ob ein serviceübergreifender Ablauf das korrekte Ergebnis liefert, sagt es Ihnen nicht.
Consumer-driven oder producer-driven?
Consumer-driven findet mehr echte Fehler, weil es festhält, was Consumer tatsächlich nutzen, statt dessen, was der Producer anbieten wollte.
Brauchen wir weiterhin Integrationstests?
Weniger davon, genau darum geht es. Behalten Sie einen kleinen Satz für Abläufe, die sich über mehrere Services erstrecken, und überlassen Sie die Strukturfrage den Contracts.
Und wenn wir beide Seiten selbst kontrollieren?
Der Nutzen sinkt, weil Sie beides gemeinsam ändern können. Am wertvollsten ist es, wenn Teams unabhängig voneinander deployen.
Richtige Struktur, unbekanntes Verhalten.
Contract Testing fängt Struktur-Drift zwischen Services günstig ab und ist bewusst blind dafür, ob eine der beiden Seiten korrekt ist. Lassen Sie es zur Build-Zeit laufen und stellen Sie ihm eine Verhaltensprüfung gegen die laufenden Services zur Seite.