Schnittstellentests: Warum gültiges JSON noch keine kompatible Änderung bedeutet

Eine Schnittstelle liefert syntaktisch korrektes JSON und entspricht sogar ihrem Schema. Trotzdem funktioniert der angebundene Prozess nach einem Update nicht mehr. Kompatibilität betrifft mehr als die äußere Form einer Nachricht.

Verbraucher haben konkrete Erwartungen

Ein System, das eine API verwendet, erwartet bestimmte Felder, Werte und Verhaltensweisen. Verbrauchergesteuerte Vertragstests bilden solche tatsächlich genutzten Interaktionen als überprüfbare Beispiele ab. Auf der Anbieterseite wird geprüft, ob diese Erwartungen weiterhin erfüllt werden.

Das ergänzt eine Schnittstellenspezifikation. Ein Schema beschreibt mögliche Strukturen; ein konkreter Test kann beispielsweise prüfen, wie ein bestimmter Anfragefall beantwortet wird. Nicht jede fachliche Bedeutung lässt sich allein aus einem Datentyp ableiten.

Ein selbst entwickeltes Beispiel

Ein Planungsprozess liest den Status „bereit“ und startet danach eine Übergabe. Eine neue API-Version ergänzt weitere Statuswerte. Strukturell bleibt das Feld eine Zeichenkette und das JSON gültig. Wenn der Verbraucher nur zwei bekannte Werte verarbeitet, kann die neue Antwort trotzdem zu einem falschen Standardpfad führen.

Ein geeigneter Test prüft deshalb nicht nur das Vorhandensein des Feldes. Er zeigt, welche Werte der Verbraucher benötigt und wie er auf unbekannte Werte reagiert. Auch eine Umstellung von „fehlend“ auf einen ausdrücklich gesetzten Nullwert kann relevant sein, wenn beide Fälle unterschiedlich behandelt werden.

Verträge gezielt und nicht unnötig eng formulieren

Ein Test, der jedes ungenutzte Feld exakt festschreibt, kann harmlose Erweiterungen blockieren. Eine zu lockere Prüfung übersieht dagegen Veränderungen, die den Ablauf tatsächlich betreffen. Die Grenze sollte sich an der konkreten Verwendung orientieren.

Bei einer Datumsangabe kann beispielsweise entscheidend sein, ob Zeitzone und Format eindeutig sind. Bei einer Liste können Reihenfolge, leere Ergebnisse und mehrseitige Antworten relevant sein. Diese Erwartungen müssen vor einer Änderung bekannt sein, nicht erst nach einer Störung.

Kein Ersatz für das Gesamtsystem

Ein bestandener Vertragstest belegt die geprüften Interaktionen. Er ersetzt keine Prüfung von Berechtigungen, Laufzeitverhalten, Netzwerkausfällen oder einem vollständigen fachlichen Ablauf. Für eine Freigabe werden die jeweiligen Nachweise zusammengeführt.

In großen Projekten hilft eine Übersicht darüber, welcher Verbraucher welche Version einer Schnittstelle nutzt. Dadurch werden Änderungen gezielter abgestimmt. Der Test wird zu einem konkreten Abstimmungswerkzeug zwischen Teams und nicht nur zu einer weiteren grünen Anzeige im Build.