Contract Tests – Wer braucht das wirklich?

Schnittstellen zu testen wird oft aufgeschoben, weil unklar ist, wie man es richtig anpackt. Dabei gibt es zwei bewährte Wege: Repository-basiertes Testing mit Open API und Renovate prüft automatisch Strukturänderungen, während Consumer-Driven Contract Testing mit Pact auch die Semantik absichert und Teams unabhängig voneinander arbeiten lässt. Beide Ansätze lassen sich schrittweise einführen, in bestehende Pipelines integrieren und nehmen Software Testing von Schnittstellen die Komplexität – wenn man weiß, welcher Weg zum eigenen Setup passt.

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

Consumer-Driven Contract Testing sichert Semantik ab, Renovate nur Syntax – beides zusammen schützt Schnittstellen vollständig.
Wer APIs mit Contract Testing absichert, kann ohne Wartezeit auf andere Teams parallel entwickeln.
Pact-Tests sind JUnit-Tests – Build schlägt fehl, wenn Contracts brechen, niemand kann sich drücken.
Contract Testing lohnt sich auch ohne Pactbroker – Tests lokal schreiben, Contracts per Filesystem austauschen.
Kommunikation bleibt Pflicht – auch mit Contract Testing muss man reden, wenn Tests fehlschlagen.

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.