© Liashko/Shutterstock.com
Entwickler Magazin
Microservices: Consumer-driven Contract Testing mit Pact

Verträge sind einzuhalten

„Pacta sunt servanda“, oder zu deutsch „Verträge sind einzuhalten“: Was schon im Mittelalter galt, soll in der modernen Welt der Software auch verbindlich sein. Mithilfe von (API-)Verträgen, die nicht nur durch einen, sondern mehrere Vertragspartner gestaltet werden, lassen sich Microservices-Architekturen einfach und effizient testen und weiterentwickeln.

Tobias Bayer, Hendrik Still


„Microservices“ [1] ist eines der Schlagwörter schlechthin, wenn im Moment über moderne Softwarearchitektur gesprochen und geschrieben wird. Dabei handelt es sich um einen Architekturstil, bei dem die Geschäftsfunktionen einer Anwendung auf viele kleine Services verteilt werden. Jeder Service läuft in seinem eigenen Prozess und ist typischerweise für genau eine klar definierte Geschäftsfunktion zuständig. Die Services kommunizieren untereinander meist über Webtechnologien wie z. B. HTTP/REST oder aber auch über einen Message Bus. Eine Microservices-Applikation erfüllt die an sie gestellten Anforderungen durch das Zusammenspiel der einzelnen Microservices. So kann eine Applikation zur Darstellung von Produktinformationen z. B. aus folgenden Microservices bestehen: Beschreibung, Preis, Kundenbewertungen und Lagerbestand.

Herausforderungen beim Testen

Vorteile einer Microservices-Architektur sind unter anderem Skalierbarkeit (sowohl der Software selbst als auch des Entwicklungsteams), Ausfallsicherheit, Sprach- und Technologieunabhängigkeit sowie erhöhte Flexibilität. Allerdings bringt ein solches verteiltes System auch Nachteile mit sich, z. B. den komplizierteren Betrieb, Codeduplikation, Netzwerklatenz, verteilte Transaktionen, zusätzliche Schnittstellen und schwierigere Testbarkeit [2]. Für all diese Probleme existieren aber Lösungsansätze. In diesem Artikel sollen Consumer-driven Contracts als Lösungsmöglichkeit für die beiden letztgenannten Nachteile der zusätzlichen Schnittstellen und Testbarkeit vorgestellt werden.

Beim Testen einer Anwendung, die aus Microservices besteht, ergeben sich gegenüber einer monolithischen Architektur eine Reihe spezieller Herausforderungen [3]. Die auf den unteren Ebenen angesiedelten Tests (beispielsweise Unit Tests) können weiter wie gewohnt entwickelt werden. Damit aber eine Applikation ihre Aufgabe erfüllen kann, ist in einer Microservices-Architektur stets ein Zusammenwirken einzelner Microservices notwendig. Sobald also Schnittstellen zu anderen Microservices im Spiel sind oder die Antworten eines anderen Microservice benötigt werden, um die eigene Funktionalität zu testen, stellt sich die Frage, wie diese Abhängigkeiten zur Verfügung gestellt werden können.

Üblicherweise will man zum Testen eines Microservice nicht die komplette Landschaft der Services hochfahren. Dadurch würden die großen Vorteile einer Microservices-Architektur verspielt werden, nach denen einzelne Microservices unabhängig entwickelt, gewartet und...

Entwickler Magazin
Microservices: Consumer-driven Contract Testing mit Pact

Verträge sind einzuhalten

„Pacta sunt servanda“, oder zu deutsch „Verträge sind einzuhalten“: Was schon im Mittelalter galt, soll in der modernen Welt der Software auch verbindlich sein. Mithilfe von (API-)Verträgen, die nicht nur durch einen, sondern mehrere Vertragspartner gestaltet werden, lassen sich Microservices-Architekturen einfach und effizient testen und weiterentwickeln.

Tobias Bayer, Hendrik Still


„Microservices“ [1] ist eines der Schlagwörter schlechthin, wenn im Moment über moderne Softwarearchitektur gesprochen und geschrieben wird. Dabei handelt es sich um einen Architekturstil, bei dem die Geschäftsfunktionen einer Anwendung auf viele kleine Services verteilt werden. Jeder Service läuft in seinem eigenen Prozess und ist typischerweise für genau eine klar definierte Geschäftsfunktion zuständig. Die Services kommunizieren untereinander meist über Webtechnologien wie z. B. HTTP/REST oder aber auch über einen Message Bus. Eine Microservices-Applikation erfüllt die an sie gestellten Anforderungen durch das Zusammenspiel der einzelnen Microservices. So kann eine Applikation zur Darstellung von Produktinformationen z. B. aus folgenden Microservices bestehen: Beschreibung, Preis, Kundenbewertungen und Lagerbestand.

Herausforderungen beim Testen

Vorteile einer Microservices-Architektur sind unter anderem Skalierbarkeit (sowohl der Software selbst als auch des Entwicklungsteams), Ausfallsicherheit, Sprach- und Technologieunabhängigkeit sowie erhöhte Flexibilität. Allerdings bringt ein solches verteiltes System auch Nachteile mit sich, z. B. den komplizierteren Betrieb, Codeduplikation, Netzwerklatenz, verteilte Transaktionen, zusätzliche Schnittstellen und schwierigere Testbarkeit [2]. Für all diese Probleme existieren aber Lösungsansätze. In diesem Artikel sollen Consumer-driven Contracts als Lösungsmöglichkeit für die beiden letztgenannten Nachteile der zusätzlichen Schnittstellen und Testbarkeit vorgestellt werden.

Beim Testen einer Anwendung, die aus Microservices besteht, ergeben sich gegenüber einer monolithischen Architektur eine Reihe spezieller Herausforderungen [3]. Die auf den unteren Ebenen angesiedelten Tests (beispielsweise Unit Tests) können weiter wie gewohnt entwickelt werden. Damit aber eine Applikation ihre Aufgabe erfüllen kann, ist in einer Microservices-Architektur stets ein Zusammenwirken einzelner Microservices notwendig. Sobald also Schnittstellen zu anderen Microservices im Spiel sind oder die Antworten eines anderen Microservice benötigt werden, um die eigene Funktionalität zu testen, stellt sich die Frage, wie diese Abhängigkeiten zur Verfügung gestellt werden können.

Üblicherweise will man zum Testen eines Microservice nicht die komplette Landschaft der Services hochfahren. Dadurch würden die großen Vorteile einer Microservices-Architektur verspielt werden, nach denen einzelne Microservices unabhängig entwickelt, gewartet und...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang