Mule Test Recorder: MUnit-Tests wie von Zauberhand in Mule 4

Vor Kurzem wurde der Mule Test Recorder in Mule 4 vorgestellt. Dieser verspricht eine Zeitersparnis bei der Erstellung von MUnit-Tests.
Dafür muss lediglich die jeweilige Applikation gestartet werden. Während der laufenden Anwendung werden dann sämtliche Ein- und Ausgabedaten aufgezeichnet. Aus diesen Daten wird anschließend automatisch der MUnit-Test erstellt.
Dieses neue Feature stellen wir im Folgenden vor.

Technische Vorraussetzungen

Um den neuen Test Recorder nutzen zu können, werden folgende Versionen vorausgesetzt:

• Anypoint Studio 7.5.0 oder aktueller
• MUnit 2.2.5
• MUnit Anypoint Studio Plugin 2.5.0
• Mule runtime engine 4.3.0

Die aktuelle Version des Anypoint Studio kann hier heruntergeladen werden.

Wie funktioniert das Ganze?

Die Vorgehensweise, um einen Testfall aufzuzeichnen, beschreiben wir in einer Schritt-für-Schritt-Anleitung.
Zuerst haben wir eine kleine Applikation erstellt, die wir dafür nutzen.

Das Beispielprojekt

In unserem Beispiel kann ein Nutzer einen HTTP-Request an unsere Applikation schicken. Wenn der Body dabei „codecentric“ beinhaltet, wird die URL der codecentric-Webseite als Response geliefert. In allen anderen Fällen erhält der Nutzer die Antwort, dass die Anfrage zu keinem Ergebnis geführt hat.

Das Ganze sieht dann wie folgt aus:

Ansicht des zu testenden Flows

Aufnahme des Testfalls

Wir haben zu diesem Zeitpunkt also den oben beschriebenen Flow vorliegen und können nun mit dem Prozedere zur Aufzeichnung beginnen.

Schritt 1

Als ersten Schritt müssen wir unsere Anwendung unter Einbeziehung des Test Recorders starten. Dafür klicken wir mit der rechten Maustaste auf unseren Flow und wählen „MUnit“ > „Record test for this flow“.

Die Anwendung wird nun in einem Test-Record-Modus gestartet. Nach Abschluss des Vorgangs vermeldet ein Fenster im Anypoint Studio, dass der Test Recorder bereit ist, etwas aufzunehmen.

Schritt 2

Nun sind wir in der Lage, unseren Flow mit einem HTTP-Request zu starten. Dafür senden wir aus meinem REST-Client heraus eine Anfrage an unsere Anwendung und bekommen hier nachweislich die erwartete Antwort:

Nun können wir wieder in das Anypoint Studio wechseln und stellen fest, dass der Test Recorder im Hintergrund gearbeitet hat.

Schritt 3

In dem Fenster kann man jetzt auf „Configure test“ klicken. Dies öffnet ein neues Fenster, das es ermöglicht, noch einige Einstellungen für unseren Test vorzunehmen.

Auf der ersten Seite können wir den Namen des Tests und den Namen der Datei festlegen, in welcher der MUnit Test erstellt wird. (Der Name des Tests wird auch für das Package genutzt, in dem alle testbezogenen Dateien erstellt werden. Der Name des MUnit Tests „introducing-test-recorder-flow-test“ wird dabei zu dem Package-Namen „introducingtestrecorderflowtest“. Bei Bedarf kann man daran nachgelagert manuelle Anpassungen vornehmen.)

Auf der zweiten Seite hat man links eine Übersicht über alle innerhalb des Tests ausgeführten Message-Prozessoren. Auf der rechten Seite kann man weiter spezifizieren, welche Inhalte geprüft werden sollen. So kann man festlegen, dass neben einem Assert für den Payload auch die Attribute oder ggf. Variableninhalte geprüft werden sollen.

Auf der letzten Seite liefert der Test Recorder nochmals einen Überblick über die getroffenen Entscheidungen.

Wir können die Konfiguration nun mit „Finish“ beenden und schon beginnt die automatische Erstellung des MUnit-Tests.

Das Resultat

Im Hintergrund hat Mule nun eine Datei mit einem MUnit-Test erstellt, der unseren Vorgaben aus der Aufzeichnung entspricht. Alle Input und Output Parameter wurden dabei in *.dwl Dateien unter „test/resources/introducingtestrecorderflowtest“ abgelegt.

In einem weiteren Schritt kann man nun natürlich die Prozedur zum Erstellen eines MUnit-Test für den zweiten Zweig der Anwendung wiederholen. Dies haben wir auf Grund der hohen Übereinstimmung des Vorgangs in diesem Artikel ausgelassen.

Limitierungen

Leider gibt es einige Limitierungen. So ist es zum Beispiel aktuell nicht möglich, Message-Mocks direkt vor oder innerhalb von For-each-Schleifen zu nutzen. Eine Liste dieser (bekannten) Limitierungen gibt es hier .
Ob diese Einschränkungen zukünftig wegfallen werden, bleibt abzuwarten.

Einordnung

Inwieweit diese Einschränkungen den Einsatz des Mule Test Recoders in seinem eigenen Projekt behindern oder gar verhindern muss jeder selbst für sich entscheiden.

Klar ist, dass sich der Einsatz wohl erst lohnt, wenn man zum Einen gleich mehrere Tests für verschiedene Mule-Flows erstellen möchte und zum Anderen diese auch bereits im Vorfeld gut vorbereitet hat bzw. vorbereiten kann. Wie immer steht und fällt die Qualität der Tests mit der Qualität des Testdatensets, auf das sie aufbauen. Ist bereits viel Vorarbeit in den Aufbau eines Regressionsdatensets geflossen (z. B. in Form von Postman-, SoapUI- oder Insomnia-Collections), so erspart man sich mit dem Mule Test Recorder u. U. viel Zeit bei der Erstellung von dazu passenden Testfällen.

Bei dem sinnvollen Anlegen oder Strukturieren solch einer Collection hilft der Mule Test Recoder nicht, er bietet aber die Möglichkeit, sie mit dem erwarteten Verhalten der Anwendung entsprechend zu „konservieren“. Dabei empfiehlt es sich, die generierten MUnit-Tests an die Namenskonvention der Testdaten-Collections anzupassen, damit eine gewisse Traceability gegeben ist. Dann können die Tests einem Release Manager dabei helfen, zu ermitteln, ob die Anwendungen immer noch so reagieren wie vor einer Änderung oder ob ein Rollback erforderlich ist.

Beim Ableiten von Testfällen von den Testdaten-Collections ist allerdings besondere Vorsicht geboten beim Setzen von Häkchen bei Payload, Attributen und Variablen, denn wenn man hier nicht sauber trennt zwischen Umgebungs-, Release- und anwendungsabhähngigen Werten, ist das eher kontraproduktiv bei der anschließenden Bewertung der Testergebnisse.

Für die Erstellung von einmaligen Tests oder am Anfang eines Projektes, bei dem nur eine Handvoll Mule Flows existieren, ist der Mule Test Recorder sicherlich noch nicht interessant. Im späteren Verlauf, wenn bereits umfangreichere Testdaten und Programmversionen erstellt wurden, kehrt sich dieses Bild aber möglicherweise ins Gegenteil um.
Als Einsatzszenario sehen wir also eher die Erstellung von Regressionstests und empfehlen beim Einsatz eine enge Abstimmung mit dem Release Management. Inwieweit der Test Recorder auch bei einem TDD-Ansatz lohnend eingesetzt werden kann, bleibt abzuwarten.

Fazit

Der Mule Test Recorder bietet eine einfache Möglichkeit, um MUnit-Tests automatisiert zu erstellen. In einfachen Fällen – wie meinem Beispiel – funktioniert dies auch ohne weiteres Zutun.

In komplexeren Fällen muss man durchaus nach dem Erstellen eines Tests noch selbst Hand anlegen, um die gewünschten Ergebnisse zu erhalten. Auch kann es aufgrund der Limitierungen sein, dass diverse Konstellationen eine umfassende, automatische Erstellung eines MUnit-Tests verhindern. Nichtsdestotrotz kann man auf diese Art und Weise bereits ein Testgerüst erstellen, das man beliebig erweitern und für weitere Tests nutzen kann.

Gerade Neulingen in Mule würden wir aber empfehlen, Tests immer komplett manuell zu erstellen, um ein Verständnis dafür zu entwickeln, wie MUnit-Tests funktionieren und so auf evtl. auftretende Probleme effizient reagieren zu können.

Wir wünschen viel Spaß beim Testen und wie immer freuen wir uns über Fragen, Kritik oder Anregungen.