Ausblick auf die Punsch Session zu Consumer-Driven Contract Testing

Microservices als Architekturstil gestalten Anwendungen skalierbarer und flexibler. Die einzelnen Services werden typischerweise von unterschiedlichen Teams entwickelt, die möglichst unabhängig voneinander arbeiten sollen. Trotzdem müssen Schnittstellen definiert werden. Consumer-Driven Contract Testing ermöglicht es den Entwicklern, Verträge zwischen den Diensten zu verwalten und so die Zuverlässigkeit und Konsistenz in einer verteilten Service-Landschaft zu gewährleisten.

Im klassischen, providergetriebenen Ansatz definiert der Service die Schnittstelle und die Clients/Consumer müssen sich danach richten. Integrations-Tests prüfen fachlich das Zusammenspiel zwischen den Services und decken somit auch technische Probleme an den Schnittstellen auf. Das passiert aber erst sehr spät in den Integrations-Tests. Und je später Fehler entdeckt werden, desto teurer wird die Beseitigung.

Durch Consumer-Driven Contract Testing (CDCT) definieren Entwickler einen bidirektionalen Vertrag (sowohl auf Consumer- als auch Providerseite). Gegen diesen Vertrag lassen sich von Anfang an leichtgewichtige Unit-Tests ausführen. Bei Änderungen an der Server-Seite zeigt sich sehr schnell, ob für einige der Clients die Schnittstelle gebrochen ist und somit der Vertrag neu verhandelt werden muss. CDCT stellt damit sicher, dass die Schnittstellen den Erwartungen der Verbraucher (Consumer) entsprechen, ohne dass die Produzenten (Provider) und Verbraucher direkt über schwergewichtige Integrations-Tests miteinander interagieren müssen.

Die Verbraucher von Diensten (Client-Anwendungen) bestimmen, welche Funktionen und Daten sie von den Produzenten erwarten. Sie definieren diese Erwartungen in Form von Tests, die als Verträge bezeichnet werden. Diese Verträge werden von den Produzenten akzeptiert und in ihre Entwicklungsprozesse integriert. Das bedeutet, dass die Produzenten ihre Dienste so gestalten, dass sie die Verträge erfüllen. Und die Verbraucher können sicher sein, dass die Dienste die erwarteten Ergebnisse liefern.

Wie funktioniert Consumer-Driven Contract Testing?

Der Prozess besteht aus mehreren Schritten. Die Verbraucher definieren die Erwartungen an die Schnittstelle zunächst als Testfall und definieren so auch, wie die Daten aussehen sollen. Die daraus entstandene Schnittstellenbeschreibung wird an den Produzenten weitergegeben. Dieser validiert den Vertrag gegenüber seiner Implementierung und stellt somit sicher, dass die erwarteten Anforderungen erfüllt sind. Da die Verträge über automasierte Tests umgesetzt sind, kann regelmässig auf beiden Seiten geprüft werden, ob sich sowohl Produzenten als auch Konsumenten daran halten. Die Verbraucher wissen genau, welche Daten sie erwarten können und die Service-Seite weiß, welche Anforderungen erfüllt werden müssen. Bei nicht abwärtskompatiblen Änderungen muss entsprechend neu verhandelt und die Tests müssen angepasst werden.

Consumer erwarten einen Vertrag und schreiben diese Erwartungen in einen Test

Diese Tests werden gegen einen Mock-Provider ausgeführt und die daraus erzeugte Vertrags-Datei wird mit anderen Teams geteilt

Auf der Service-Seite wird die Implementierung gegen einen Mock-Consumer getestet

Machen Client oder Server nicht-kompatible Änderungen kommt es frühzeitig zum Fehler

Consumer-Driven Contract Testing bietet eine Vielzahl von Vorteilen:

• CDCT erhöht die Zuverlässigkeit in verteilten Systemen, Verträge stellen sicher, dass die Dienste die erwarteten Ergebnisse liefern.
• Verbraucher und Produzenten können unabhängig voneinander und somit schneller arbeiten, da sie sich auf die Verträge verlassen können. Änderungen in den Diensten müssen die Verträge erfüllen, um akzeptiert zu werden.
• durch die automatisierten Tests auf Basis der Verträge werden Fehler frühzeitig erkannt und behoben, bevor sie in die Produktion gelangen

Fazit

Besonders im agilen Umfeld ist Consumer-Driven Contract Testing ist eine leistungsstarke Methode, um die Zuverlässigkeit und Konsistenz in beispielsweise einer Microservices-Architektur sicherzustellen. Die Consumer kommunizieren ihre Erwartungen in Form von Verträgen, die im weiteren Verlauf der Entwicklung zwischen den Teams ausgetauscht werden. Sie bilden die Grundlage für frühzeitiges Feedback in Form von Unit-Tests sowohl auf der Consumer- als auch der Provider-Seite. Unstimmigkeiten und fehlerbehaftete Änderungen an den Schnittstellen werden dadurch früh entdeckt. Die Teams können autark arbeiten und müssen auch nicht übergreifend aufwendige Integrations-Tests erstellen und pflegen.

Mehr Details, insbesondere konkrete Implementierungsbeispiele und noch mehr Anregungen erhaltet Ihr am 14. Dezember 2023 bei unserem Architektur-Punsch. Einfach anmelden! Neben meinem Vortrag zu diesem Thema gibt es dort viele weitere spannende Programmpunkte zu entdecken.

zu den weiteren Punsch Blog-Posts