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

Keine Kommentare

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:

system ed-to-end

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:

Bildschirmfoto 2015-06-09 um 22.24.31

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:

{
  "port": 9000,
  "protocol": "http",
  "name": "My Mock",
  "mode": "text",
  "stubs": [
    {
      "responses": [
        {
          "is":
          {
            "statusCode": 200,
            "headers": {
              "Content-Type": "application/json"
            },
            "body": "{ \"message\": \"You got mocked data\" }"
          }
        }
      ],
      "predicates": [
        {
          "equals": {
            "path": "/anotherResource"
          }
        }
      ]
    }
  ]
}

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.

Conrad ist Business Development Manager bei der codecentric AG. Er sieht sich selbst als „Coding-Software-Architekt“, Entwickler und in allen anderen Rollen, die für die erfolgreiche Durchführung eines Projekts vonnöten sind. Derzeit fokussiert er sich auf dem Aufbau der Partnerschaft mit Amazon Web Services und auf die in dem Rahmen entstehenden Projekte. Sein persönliches Ziel ist es, nach neuem Wissen in der IT-Industrie zu streben.

In seiner Freizeit macht er sich in Berlin für die IT Community stark, als Gründer und Hauptorganisator des Microservices Meetups Berlin, Co-Organizer des DDD Meetups, des Serverless Meetups und als Mitglied im Organisations-Komitee der MicroXchg Konferenz und KanDDDinsky der Berliner DDD Konferenz.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

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