Contract Tests – Wer braucht das wirklich?

APIs sind die Nervenbahnen digitaler Produkte. Wenn Teams wachsen und Systeme sich schneller ändern, kippt Vertrauen ohne klare Verträge. Zwei Wege sorgen für verlässliche Schnittstellen. Versionierte OpenAPI-Spezifikationen, gekoppelt mit Renovate, machen Änderungen transparent und halten Abhängigkeiten sauber, sie prüfen jedoch primär die Syntax. Mehr fachliche Sicherheit liefern Consumer-driven Contract Tests mit Pact. Der Consumer formuliert Erwartungen, der Pact Broker stellt Mocks bereit, und die Pipeline bricht Releases bei Vertragsbrüchen ab. So entstehen schnelle Rückmeldungen ohne Gegensystem.

Podcast Episode: Contract Tests – Wer braucht das wirklich?

In dieser Episode spreche ich mit Andrej Thiele über API Testing. Andrej zeigt zwei praxistaugliche Wege. Erstens: OpenAPI versionieren und mit Renovate Abhängigkeiten und Änderungen sichtbar machen. Zweitens: Consumer-driven Contract Tests mit Pact. Der Consumer definiert Erwartungen, Pactbroker stellt Mocks bereit und JUnit bindet es in die Pipeline ein. Brechen Contracts, stoppt der Release. Reden müssen Teams trotzdem.

"Es bietet sich immer an, auch das auf OpenAPI zu basieren und sich seine Schnittstelle einfach generieren zu lassen, weil das auch einen Haufen Arbeit spart bei der Programmierung und halt nicht so fehlerträchtig ist." - Andrej Thiele

Nach seinem Diplom in Informatik an der TU Dortmund 1999, arbeitete Andrej als Softwareentwickler bei Firmen in unterschiedlichen Bereichen der Industrie, z.B. Digitalisierung von Radiosendern, Telekommunikation, Mobile und Embedded Devices. Im Jahr 2008 wechselte er in die Beratung und agierte dort als Senior Consultant in verschiedenen Projekten in der Rolle vom Entwickler, Architekten, technischen Projektleiter bis hin zum Test Coach für Entwickler. Seit 2016 arbeitet er bei der Firma Conciso GmbH und veranstaltet dort unter anderem ein regelmäßiges Coding Dojo als MeetUp und ist als Topic Lead für Qualitätssicherung in der Weiterbildung der internen Mitarbeiter sowie der Durchführung von Schulungen bei Kunden tätig. Zusätzlich ist er regelmäßig als Sprecher auf verschiedenen Konferenzen zu sehen.

Highlights der Episode

• OpenAPI versionieren schafft Struktur, prüft aber nur Syntax
• Renovate macht API-Änderungen und Abhängigkeiten sichtbar
• Consumer-driven Contracts mit Pact sichern Erwartungen und entkoppeln Tests vom Gegensystem
• Contract-Tests blockieren Releases bei Vertragsbrüchen
• Teams müssen trotz Contracts miteinander reden

API‑Testing: Was steckt dahinter?

APIs bestimmen unseren digitalen Alltag. Sie verbinden Systeme, machen Apps möglich und sorgen dafür, dass Daten sicher und effizient fließen. Trotzdem bleiben viele Fragen offen: Wie testet man APIs sinnvoll? Welche Methoden gibt es? Und wie baut man sie so, dass Fehler schnell auffallen? Genau davon handelte das Gespräch von Richie mit André Thiele und André Thiele auf der Tacon-Konferenz.

Kommunikation ist wichtig, reicht aber nicht

Oft startet API‑Testing ganz einfach: Die Teams reden miteinander. Sie setzen sich zusammen, gehen die Anforderungen durch und stimmen sich ab. Das klingt logisch, kann im Alltag aber schnell Probleme machen. Vielleicht arbeiten Teams an verschiedenen Standorten. Vielleicht versteht man sich nicht richtig. Und am Ende fehlt eine klare Definition, was die Schnittstelle wirklich leisten soll.

Deshalb bleibt es nicht beim Reden. André Thiele zeigt, dass Planung wichtig ist, aber für echte Qualität braucht es mehr: strukturierte Tests und Werkzeuge, die helfen, Fehler früh zu entdecken.

Zwei Standardwege für API‑Tests

Es gibt mehrere Ansätze, wie man APIs testen kann. Ein ziemlich verbreiteter Weg ist das Repository-basierte Testen.

Repository-Ansatz mit OpenAPI und Renovate

Hier funktioniert das Ganze so: Man beschreibt die API‑Schnittstelle einmal sauber, zum Beispiel mit OpenAPI. Diese Datei liegt im Versionsmanagement und kann von Tools wie Renovate überwacht werden. Immer wenn sich etwas an der Schnittstelle ändert, meldet Renovate das. Es macht automatische Merge‑Requests, aktualisiert Versionen und hilft, Änderungen im Blick zu behalten.

Das klingt einfach, hat aber einen Haken: So prüft man nur die Struktur und Syntax. Wie genau Daten fließen, ob bestimmte Werte nötig oder erlaubt sind, merkt man erst mal nicht. Das Beispiel mit Enums zeigt es: Ändert ein Entwickler erlaubte Werte, sieht der Syntax‑Check das nicht zwingend. Fehler fallen dadurch später auf.

Consumer‑Driven Contract Testing

Hier setzt man beim Endnutzer an. Man nutzt Werkzeuge wie PACT. Das Prinzip: Nicht der Entwickler der Schnittstelle definiert, was getestet wird, sondern die, die die Schnittstelle nutzen. Jeder Consumer beschreibt Beispiele, also was er schickt und was er zurückerwartet. Diese Angaben landen in sogenannten Contracts und dienen als Vorlage für automatisierte Tests.

Der Vorteil: Damit prüft man, ob die API wirklich wie geplant arbeitet – und zwar auch mit echtem Inhalt, nicht nur mit einer leeren Hülle. Mehrere Verbraucher können verschiedene Bereiche der Schnittstelle abdecken. So entsteht ein echtes, lebendiges Testsystem.

Wozu das Ganze? Beispiele und Alltag

Gerade in Projekten mit mehreren Teams, Microservices und vielen Schnittstellen gibt Contract Testing echte Sicherheit. Fehlschläge im Test stoppen die Auslieferung der Software. Erst wenn alles stimmt, geht’s weiter. Fehler fallen schneller auf und können gezielt angegangen werden. Trotzdem bleibt Reden nötig. „Ganz ohne Austausch läuft es nicht“, sagt André Thiele.

Im Alltag setzt man oft Mischformen ein: Man startet vielleicht mit Syntax-Checks und baut dann Schritt für Schritt mehr Contract‑Tests ein. Die Tests selbst schreibt man im Java-Umfeld oft als einfache JUnit‑Tests und kann sie so in jede Automatisierungs‑Pipeline einhängen. Änderungen und Ergebnisse sieht man direkt beim Bauen der Software.

Ist das aufwendig?

Der Aufwand hält sich in Grenzen, wenn man sich ein wenig auskennt. Viele Tools gibt es als Docker‑Container. Mit etwas Übung kann man eine ganze Umgebung an einem Wochenende einrichten. Wer neu dabei ist, braucht länger – aber alles wächst mit der Zeit. Man kann auch erstmal klein anfangen und später mehr Consumer und Producer anbinden.

Weniger Ausreden, mehr Klarheit

APIs sind das Rückgrat moderner Software. Sie brauchen klare Verträge und gute Tests. Ob Repository-basierter Ansatz oder Contract Testing: Jedes Team muss entscheiden, wie viel Sicherheit und Automatisierung passt. Das Beste? Man kann wachsen und immer mehr Qualität und Transparenz schaffen. Am Ende gilt: Testen lohnt sich. Mit guten APIs gibt es weniger böse Überraschungen – und die Teams verstehen sich besser, auch wenn sie trotzdem reden müssen.