Contract Testing: warum Schnittstellen still brechen und wie man das abstellt
Zwei Teams, eine Schnittstelle: Das eine ändert ein Feld, das andere merkt es beim nächsten Vorfall. Dieser Ablauf ist kein Zeichen schlechter Zusammenarbeit, sondern die logische Folge fehlender Rückmeldung — und er wird häufiger, je mehr Änderungen es gibt.
Vertragstests schließen die Rückmeldungslücke zwischen Teams: Der Aufrufer beschreibt seine Erwartung an eine Schnittstelle, diese Beschreibung läuft als Test im Build des Anbieters. Ein Bruch fällt vor dem Zusammenführen auf, im Verantwortungsbereich des Verursachers. Integrationstests kommen dafür zu spät und sind zu langsam. Einstieg an der Schnittstelle mit den meisten Vorfällen; die Erwartungen müssen vom Aufrufer stammen.
Warum Integrationstests das Problem nicht lösen
Weil sie zu spät kommen und zu langsam sind. Ein vollständiger Integrationstest über mehrere Dienste läuft nachts oder in einer Vorstufe, oft mit Testdaten, die nicht alle Fälle abbilden. Bis eine Abweichung auffällt, ist die Änderung längst zusammengeführt — und die Rückverfolgung kostet ein Vielfaches der Änderung selbst.
Wie ein Vertragstest funktioniert
Der Aufrufer beschreibt, was er von der Schnittstelle erwartet: welche Felder, welche Typen, welches Verhalten in Fehlerfällen. Diese Erwartung wird zu einer Datei, und die Datei läuft als Test gegen den Anbieter. Ändert der Anbieter etwas, das eine bestehende Erwartung verletzt, schlägt sein Build fehl — vor dem Zusammenführen, in seinem eigenen Verantwortungsbereich, mit dem Namen des betroffenen Aufrufers im Fehlertext.
Was das organisatorisch ändert
Mehr als technisch. Die Erwartungen werden explizit, und damit wird sichtbar, wer eine Schnittstelle tatsächlich nutzt — häufig mehr Teams als gedacht, und regelmäßig eines, von dem der Anbieter nichts wusste. Diese Sichtbarkeit ist der eigentliche Ertrag, weil sie Abstimmungen ermöglicht, die vorher gar nicht stattfinden konnten.
Der Einstieg
Nicht flächendeckend, sondern an der Schnittstelle mit den meisten Vorfällen. Zwei Teams, eine Schnittstelle, zwei Wochen: Danach ist erkennbar, ob das Verfahren im eigenen Haus trägt. Wichtig ist, dass die Erwartungen vom Aufrufer kommen — ein vom Anbieter geschriebener Vertrag beschreibt nur, was er ohnehin liefert, und findet nichts.
Warum das bei hohem Änderungsvolumen unverzichtbar wird
Weil die Wahrscheinlichkeit eines stillen Bruchs mit jeder Änderung steigt und die Zahl der Änderungen steigt. Ein Verfahren, das auf Aufmerksamkeit beruht — jemand liest die Änderung und denkt an die Auswirkungen — skaliert genau so gut wie der zeilenweise Review, nämlich nicht.
Häufige Fragen
Welche Werkzeuge sind üblich?
Pact ist der verbreitetste Vertreter, daneben Spring Cloud Contract im Java-Umfeld und schemabasierte Ansätze über OpenAPI oder Protobuf. Für den Einstieg ist die Werkzeugwahl zweitrangig — entscheidend ist, dass die Erwartung des Aufrufers im Build des Anbieters landet.
Funktioniert das auch mit externen Anbietern?
Eingeschränkt: Man kann die eigene Erwartung als Test gegen eine Testumgebung des Anbieters laufen lassen und wird dann früher gewarnt. Der volle Nutzen entsteht erst, wenn der Anbieter den Test in seinem eigenen Build ausführt — bei internen Teams ist das der Normalfall.
Ersetzt Contract Testing die Integrationstests?
Es ersetzt den größten Teil ihres Zwecks und macht sie schneller: Wenn Verträge geprüft sind, bleiben für die Integration nur noch die Fälle, in denen das Zusammenspiel mehrerer Dienste eine Rolle spielt. Diese Tests werden dadurch weniger und aussagekräftiger.
Wie geht man mit gewollten Änderungen an einer Schnittstelle um?
Über eine Versionierung des Vertrags und eine Übergangsfrist, in der beide Erwartungen erfüllt werden. Der Unterschied zu heute ist nicht, dass Änderungen unmöglich werden, sondern dass sie sichtbar und abgestimmt stattfinden.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
AI Engineering Review ansehen →
