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

Keine Kommentare

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:

simple-flow mule test recorder

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“.

record-flow-start

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.

test-recorder-ready

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:

test-recorder-request-sample

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

recorder-finished-window

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.)

test-config-1

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.

test-config-2

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

test-config-3

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.

final-view

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.

Tags

Pasquale Brunelli

Pasquale Brunelli hat im Jahr 2011 die Ausbildung zum Fachinformatiker bei der codecentric AG zusammen mit einem berufsbegleitenden Studium der Wirtschaftsinformatik begonnen.

Seit dem erfolgreichen Abschluss von Ausbildung und Studium ist er als IT-Consultant und Developer im Hause tätig.

Stefan Koch

Bevor Stefan Koch zu CodeCentric kam war er 13 Jahre bei IBM als IT Architekt tätig. Er pflegt eine Vorliebe für Skript-Programmiersprachen (python,php,perl,bash), fühlt sich aber auch in Java-Enterprise-Umgebungen zuhause und betreut Kunden bei Themen wie DevOps, TDD, CleanCode, Security und API Management. Ein strukturiertes Vorgehen bei der Anforderungsanalyse, Datenmodellierung sowie dem Design, API- und Test-Management hält er für genauso wichtig wie das stetige Ausprobieren neuer Tools, Technologien, Methoden und OpenSource Libraries. In seiner Freizeit geht er gerne Tauchen und Kiteboarden.

Über 1.000 Abonnenten sind up to date!

Die neuesten Tipps, Tricks, Tools und Technologien. Jede Woche direkt in deine Inbox.

Kostenfrei anmelden und immer auf dem neuesten Stand bleiben!
(Keine Sorge, du kannst dich jederzeit abmelden.)

* Hiermit willige ich in die Erhebung und Verarbeitung der vorstehenden Daten für das Empfangen des monatlichen Newsletters der codecentric AG per E-Mail ein. Ihre Einwilligung können Sie per E-Mail an datenschutz@codecentric.de, in der Informations-E-Mail selbst per Link oder an die im Impressum genannten Kontaktdaten jederzeit widerrufen. Von der Datenschutzerklärung der codecentric AG habe ich Kenntnis genommen und bestätige dies mit Absendung des Formulars.

Weitere Inhalte zu API-Management

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.