Testen von Mule-ESB-Applikationen (Teil 3/3): System-End-To-End-Tests mit Docker

Abstrakt

Im allgemeinen Konsens wird das Testen von Software als integraler Bestandteil des Software-Entwicklungsprozesses gesehen. Tests sollten in allen Phasen der Softwareentwicklung eingesetzt werden: von Unit- bis zu Akzeptanztests. Vor allem im Software Engineering bilden zusammenhängende und automatisierte Tests ein Sicherheitsnetz gegen regressive und inkompatible Änderungen.

In Integrationsprojekten mit Mule ESB sind diese Aspekte auch von Belang. Komponenten in Mule Flows, die Flows selber und deren Integration müssen intensiv getestet werden.

Dieser Artikel ist der letzte in einer Reihe von Artikeln zum Thema Testen von Mule-ESB-Projekten auf allen Ebenen (Teil 1 , Teil 2 ). Der Fokus in diesem Artikel liegt auf auf einem übergreifenden System-End-to-End-Test in einem Mule-Projekt, welches sich durch das Aufsetzen der Infrastruktur mit dem ESB und einem Mock Server mit der Hilfe von Docker auszeichnet.

Infrastruktur

Um einen System-End-to-End-Test für eine Mule-Applikation durchzuführen, benötigen wir drei Systemkomponenten:

• App: Zuerst brauchen wir die zu testende Mule-Applikation.
• Tester: Der Tester ist für das Testen der Anwendung verantwortlich. Das Testen kann durch einfache Tests, die die API-Aufrufe durchführen und das Ergebnis verifizieren, oder durch Test-Tools, welche komplexe orchestrierte Aufrufe durchführen, wie z. B. JMeter , durchgeführt werden.
• Mock: Zusätzlich brauchen wir einen oder mehrere System-Mocks, die Systeme darstellen, von denen die Anwendung abhängig ist. Mountebank kann solch eine Funktionalität bereitstellen.

Solch ein System-End-to-End-Test-Setup würde wie folgt aussehen:

Docker

Docker ist eine Open-Source-Technologie, die Virtualisierung von Maschinen in isolierten Containern auf einem Betriebssystem ermöglicht. Durch die Verwendung von Linux-Technologien wie Cgroups und Namespaces erlaubt es das schnelle und ressourceneffiziente Erzeugen von Containermaschinen, womit man eine portable, nachvollziehbare und konsistente Infrastruktur aufbauen kann. Dies ist vor allem für die Erstellung, Durchführung und Nachvollziehbarkeit von Testszenarien, die Infrastruktur-basiert sind, ein großer Vorteil.

Um eine bessere Integration solch eines System-End-to-End-Tests in eine Continuous Integration Pipeline sicherzustellen, ist die Verwendung von Container-Technologie von Vorteil. Die Verwendung von Docker zum Beispiel erlaubt das beschleunigte Starten einer isolierten Mule-Instanz mit der zu testenden Anwendung und dem Mock Server.

Zu testende Anwendung

Wir nehmen das folgende einfache Szenario als Beispiel. Eine Mule-Applikation stellt eine REST-API auf Port 8080 zur Verfügung und ruft intern einen REST-Backend-Service auf Port 9000 auf. Solch eine Applikation könnte wie folgt aussehen:

In diesem Beispiel sehen wir einen HTTP-Endpoint, der auf Port 8080 lauscht und der alle Anfragen an den REST-API-Router weiterleitet. Die Anfrage an /myResource wird im unteren Sub Flow landen und einen auswärtigen HTTP-Aufruf zum Server auf Port 9000 auslösen. Das Ergebnis wird in einen String transformiert und an den Aufrufer zurückgegeben. Im Falle von Exceptions greift eine Exception-Strategie und wird ein entsprechend passendes Ergebnis zurückliefern.

Wir nehmen an, wir haben unsere Mule-Anwendung bereits als einzelne Applikation in einem Docker-Container vorliegen, wie in diesem Blog-Artikel beschreiben.

Mock Server

Um der Mule-Applikation Aufrufe zu einem potenziellen Backend-Service in einem System-End-to-End-Szenario zu ermöglichen, kann eine Technologie wie Mountebank verwendet werden.

Mountebank ist ein Open-Source-Tool, das plattformunabhängige Multi-Protokoll-Testdoubletten auf der Netzwerkschicht bereitstellt. Eine zu testende Applikation muss nur auf die IP oder URL der Mountebank-Instanz verweisen statt auf die reale Abhängigkeit. Das ermöglicht, die Applikation durch alle Applikationsschichten zu testen, wie man es sonst traditionell mit Stubs und Mocks tun würde. Unterstützte Protokolle sind HTTP, HTTPS, TCP und SMTP.

Für unser Szenario würde der Mountebank Imposter wie folgt definiert werden, um eine gemockte Antwort auf Port 9000 zurückzugeben:

Wir nehmen an, dass der Mock Server ebenfalls in einem Docker-Container aufgesetzt wurde, wie in diesem Blog-Artikel beschrieben.

Test-Definition

Nun zu unserem Test. Wir benutzen eine einfache JUnit-Integration unter Verwendung der rest-assured Bibliothek, integriert in einem Maven-Build. Der Test ruft die REST-API auf und verifiziert, dass die Antwort die gemockten Daten des Mock Servers enthält. An diesem Punkt könnte man auch direkt über die Mountebank-REST-API die Anfragen an den Mock Server verifizieren.

Solch ein Test könnte wie folgt aussehen:

Test Konfiguration

Die Automatiserung dieses Szenarios wird mithilfe von Maven und des docker-maven-plugin erreicht. Zu diesem Zweck werden zwei Docker Images definiert, eines für die Mule-Anwendung und eines für den Mock Server:

In diesem Beispiel sind das Port Mapping und die Docker-Links zwischen den Containern erkennbar.

Um die Container für einen Test zu starten und zu stoppen, muss die folgende Integration-Test-Konfiguration aufgesetzt werden, um die Maven-Phasen zu konfigurieren:

Dies startet die Docker-Container mit docker:start vor der Maven-pre-integration-test-Phase und stoppt diese mit docker:stop in der Maven-post-integration-test-Phase.

Um diese Integrationstests auszuführen, benötigen wir das failsafe-Plugin, welches unsere System-End-to-End Tests in der Maven-integration-test-Phase inklusive Environment-Variablen ausführt.

Anmerkung: Bitte vergessen Sie nicht, das VM Port Forwarding auf Mac und Windows für boot2docker!

Test-Ausführung

Die Ausführung der Tests und ihre Integration in eine Continuous Integration oder Delivery Pipeline kann durch das „mvn verify“-Kommando durchgeführt werden. In dem Log ist zu sehen, dass alle Container starten, die Ausführung wartet, bis der Start durchgeführt wurde, die System-End-to-End-Tests durchgeführt werden und wie die Container gestoppt werden:

Fazit

Allumfassendes Testen wird gemeinhin als essentieller Bestandteil eines guten Software-Entwicklungsprozesses verstanden. Diese Tests automatisiert und auf allen Ebenen der Testpyramide durchzuführen ist erstrebenswert. Folglich ist auch das End-to-End-Testen einer Mule-Anwendung von Bedeutung.

Wir haben in diesem Artikel gezeigt, wie man eine voll automatisierte System-End-to-End-Test-Infrastruktur aufbauen kann. Wir haben dies am Beispiel vom Testen von Mule-Anwendungen mit Docker und Mountebank gemacht. Es ist aber auch möglich, dieses Test-Setup für andere Szenarien und Applikationstypen wiederzuverwenden, falls ein End-to-End-Test gewünscht ist.

Eine volles lauffähiges Beispiel dieses Szenarios befindet sich auf Github als Demo.

Serie

Dieser Artikel ist Teil einer Mule-ESB-Serie zum Thema Testen von Mule-Applikationen:

• Testen von Mule ESB Applikationen (Teil 1/3): Modultests und funktionales Testen

26161

• Testen von Mule ESB Applikationen (Teil 2/3): Integrationstests und (Endpoint) Mocking mit MUnit
• Testen von Mule ESB Applikationen (Teil 3/3): System End-to-End Tests mit Docker (dieser Artikel)