Mule-Anwendungen mit MUnit testen (Teil 1): Start im Anypoint Studio

Traditionell testet man Mule-Anwendungen mit JUnit, also Java-Code. Seit einiger Zeit bietet Mule zusätzlich MUnit an, das auch Tests als Flows realisiert. Außerdem hat das Anypoint Studio einige Wizards spendiert bekommen, mit denen sich Testfälle einfach erstellen lassen.

Mein Kollege Conrad Pöpke hat vor einiger Zeit schon über MUnit geschrieben , aber inzwischen hat sich die Welt weitergedreht und MUnit hat im Mule-Universum einen wesentlich höheren Stellenwert. Es befindet sich außerdem nicht mehr im Beta-Stadium. In diesem Blogpost zeige ich, wie man im Anypoint Studio ein einfaches Projekt aufsetzt und mit MUnit testet. Die weiteren Teile existieren bisher nur vage in meinem Kopf, ich werde mich in ihnen auf jeden Fall um die zentralen Probleme bei Tests kümmern:

1. Wie bekomme ich die Eingangsdaten in meinen Testfall?
2. Wie mocke ich Teile, die ich nicht mittesten kann (oder will)?
3. Wie verifiziere ich die Ergebnisse?

Vorbereitung

Los geht’s, Anypoint Studio starten (ich nutze aktuell 5.4.2), anschließend prüfen, ob wir aktuell sind und alle notwendigen Plugins installiert wurden: Über Help -> Check for Updates prüfen wir die Aktualität und spielen ggf. Updates ein. Je nach Studio hat man jetzt schon die volle MUnit-Unterstützung, aber auch das prüfen wir besser: Also Help -> Install New Software. Unter den Sites sollte http://studio.mulesoft.org/r4/munit schon vorhanden sein, falls nicht: bitte ergänzen. Wählt man die Site aus, darf man das MUnit-Plugin und einige Zusatzplugins installieren. Ich habe einfach mal alle ausgewählt, auch wenn wir in diesem Teil nur mit der Basis arbeiten:

Eclipse-typisch folgt nach der Installation vermutlich ein Neustart…

Mit File -> New Mule Project erstellen wir über den Wizard ein neues Projekt. Ich arbeite aktuell mit der Runtime 3.7.3 EE (im Studio darf man auch dann mit der Enterprise-Version spielen, wenn man kein zahlender Kunde ist). Damit wir später auch in einer CI-Umgebung (z.B. Jenkins) bauen können, sollte man auf jeden Fall ein Kreuz bei „Use Maven“ setzen. Das Projekt nenne ich einfach mal „munit-testprojekt“. Jetzt können wir noch eine Tasse Kaffee trinken, während Maven das halbe Internet herunterlädt, dann kann’s losgehen.

Die Mule-Anwendung enthält nur einen einfachen Flow mit einem HTTP-Endpoint:

Den HTTP-Listener habe ich auf den Port 9090 konfiguriert, der Pfad bleibt leer. Set Payload gibt eine freundliche Nachricht zurück:

Der Korrektheit wegen ist der MIME Type auf text/plain gesetzt.

Bevor wir mit der Testautomatisierung beginnen, können wir das Projekt manuell testen. Also über Run -> Run Configurations unter Mule Applications eine neue Konfiguration erstellen. In meinem Studio befinden sich im Workspace meist mehrere Mule-Projekte, für den Test wähle ich nur das munit-testprojekt aus. (Man könnte auch mit einem Rechtsklick auf das Projekt und Run as… starten, aber dort wird bei Maven-Projekten nur der Start mit Maven angeboten. Mit Maven starten die Projekte jedoch langsamer, ich gehe daher den oben beschriebenen Weg.)

Nach wenigen Sekunden sollte in der Console View stehen:

****************************************************************************
* - - + APPLICATION + - - * - - + DOMAIN + - - * - - + STATUS + - -        *
****************************************************************************
* munit-testprojekt * default * DEPLOYED                                   *
****************************************************************************

Also schnell im Browser http://localhost:9090 eintippen und über eine freundliche Begrüßung freuen:

Hello, world!

Stimmt der MIME Type? Das kann man in der Developer-Konsole seines Lieblingsbrowsers prüfen:

Content-Type:text/plain

Wer immer nur manuell testet, der kann sich jetzt zurücklehnen, mit dem Lesen aufhören und das Browser-Fenster schließen.

Noch jemand da? Gut, dann wollen wir jetzt unsere Mule-Anwendung mit einem MUnit-Test erweitern.

Maven

Der erste Schritt zu MUnit-Tests geht über Maven: ein Rechtsklick auf das Projekt, Menüpunkt MUnit -> Configure MUnit Maven Support erweitert die Datei pom.xml des Projekts. Kann man auch manuell machen, geht aber so einfacher. Was hat sich in der Datei alles geändert? Schauen wir mal:

1. In den Properties stehen die MUnit-Version (1.1.0) und die Version der Support-Bibliotheken (3.7.1).
2. Die Konfiguration des Mule-Maven-Plugins wird erweitert
3. Es kommt ein weiteres Plugin für die Ausführung der MUnit-Tests hinzu: com.mulesoft.munit.tools / munit-maven-plugin.
4. Die Test-Ressourcen werden um src/test/munit erweitert. (Jetzt darf jeder raten, in welches Verzeichnis die MUnit-Tests gehören.)
5. In den Dependencies stehen noch einige JARs mit Scope-Test für die Ausführung der Tests.

Was haben wir damit erreicht? Wir können die MUnit-Tests – die wir erst noch schreiben müssen – nicht nur im Anypoint Studio ausführen, sondern sie werden auch im Build automatisch ausgeführt.

Erster Test

Jetzt kommt endlich der erste Test, den wir ganz faul mit einem Wizard erstellen. Dafür genügt ein Rechtsklick auf unseren zu testenden Flow: MUnit -> Create new suite. Anypoint-Studio legt daraufhin die Datei munit-testprojekt-test-suite.xml im Verzeichnis src/test/munit an. Der zugehörige Test-Flow öffnet sich auch direkt im Editor:

Im XML sieht es ähnlich aus (die Namespaces habe ich durch … ersetzt):

<?xml version="1.0" encoding="UTF-8"?>
<mule ...>
  <munit:config name="munit" doc:name="Munit configuration" />
  <spring:beans>
    <spring:import resource="classpath:munit-testprojekt.xml" />
  </spring:beans>
  <munit:test name="test-munit-testprojektFlowTest" description="Test">
    <flow-ref name="munit-testprojektFlow" 
              doc:name="Flow-ref to munit-testprojektFlow" />
  </munit:test>
</mule>

Wer schon einmal einen Mule Flow in der XML-Ansicht gesehen hat, dem wird das bekannt vorkommen: Tests sind auch nur Mule Flows.

Mit einem Rechtsklick auf den Test im Flow-Editor lässt sich der Test direkt ausführen. Wenn bis hier alles glatt gelaufen ist, sollte in der MUnit-View ein grüner Balken erscheinen.

Würde ich mich strikt an meine Aussage in der Einleitung halten, könnte ich jetzt aufhören. Schließlich läuft der Test. Ganz so einfach mache ich es mir dann doch nicht: Die Payload und den MIME Type möchte ich dann doch prüfen, also werden zweimal Assert Equals aus der Mule-Palette (Abteilung MUnit) in den Flow gezogen:

Intern sieht ein Assert Equals in MUnit ähnlich wie ein assertEquals() im JUnit-Test aus:

Oder im XML:

<munit:assert-on-equals expectedValue="Hello, world!" 
                        actualValue="#[message.payload]"
                        doc:name="Check Payload"/>

Der MIME Type ist schon etwas komplizierter zu prüfen. Dazu muss man wissen, dass er sich im DataType der Mule-Message versteckt:

Damit ist das kleine Projekt inklusive Testfall vollständig. Wer mag, kann auf der Kommandozeile mittels

mvn clean test

verifizieren, dass es auch dort funktioniert. Je nach Betriebssystem kann hier noch ein kleines Problem auftauchen: Das Maven-Plugin nutzt die Bibliothek jansi , um Text auf der Konsole farbig darstellen zu können. Unter Windows versucht es daher, die Datei jansi-64.dll unter C:\Windows abzulegen. Damit das funktioniert, muss man die Maven-Tests einmalig als Administrator ausführen oder die Datei manuell dort ablegen.

Und nun?

Wie in der Einleitung versprochen (oder angedroht?), mache ich für heute Schluss. Was kommt als nächstes? Ich habe da noch ein Projekt mit einem SOAP-Service, den plane ich schon für den zweiten Teil der Serie ein. Aber ich will nicht zu weit in die Zukunft schauen…

Links

• Transformieren von Nachrichten mit Mule DataWeave – Teil 1: Einführung https://blog.codecentric.de/2015/09/esb-serie-transformieren-von-nachrichten-mit-mule-dataweave-teil-1-einfuehrung/
• Mule-Anwendungen mit MUnit testen (Teil 2): Testdaten und Asserts https://blog.codecentric.de/2016/04/mule-munit-testdaten-asserts/
• Mule-Anwendungen mit MUnit testen (Teil 3): Tabellenbasierte Tests https://blog.codecentric.de/2016/05/mule-munit-tabellenbasierte-tests/
• Testen von Mule ESB Applikationen (Teil 2/3): Integrationstests und (Endpoint) Mocking mit MUnit: https://blog.codecentric.de/2015/01/testen-von-mule-esb-applikationen-teil-23-modultests-und-funktionales-testen/
• Alle Blog-Artikel zu Mule im codecentric-Blog: https://blog.codecentric.de/?s=mule
• Was ist ein ESB und wofür kann man ihn nutzen? https://blog.codecentric.de/2012/11/was-und-wofur-esb/
• Tutorial „Enterprise Service Bus mit Mule ESB“: Hello World/Bus! https://blog.codecentric.de/2012/12/enterprise-service-bus-mule-esb/