Testen in Mule mit Datenbanken – Teil 2: In-Memory-Datenbanken

Nachdem ich im ersten Teil der Artikelserie das Mocken einer Datenbank im Rahmen von Munit-Tests beschrieben habe, werde ich im Folgenden zeigen, wie eine In-Memory-Datenbank zum Testen benutzt werden kann.

Warum sollten überhaupt In-Memory-Datenbanken zum Testen von Mule-Flows verwendet werden? Die eigentliche Logik der Flows wird in Unit-Tests üblicherweise mit gemockten Datenbanken überprüft. Allerdings werden dabei einige Aspekte der Flows einfach ausgeklammert, die in späteren Testphasen eventuell teurer zu finden und beheben sind.

Als erstes sind die Konfigurationsprameter des Connectors zu prüfen: Auch wenn die konkreten Werte für die verschiedenen Umgebungen natürlich nicht zu testen sind, kann zumindest die korrekte Syntax geprüft werden. Desweiteren wird beim Mocking der Datenbank-Aufruf selbst nicht geprüft: Also stimmt die SQL-Syntax und werden alle Parameter wie erwartet übergeben? Und zuguterletzt wird beim Mocking die Rückgabe des Ergebnisses in einem Format fest vorgegeben, das möglicherweise von dem Format abweicht, das die Datenbank tatsächlich liefert.

All das könnte man mit einer „echten“ Datenbank natürlich auch testen. Allerdings ist es deutlich aufwendiger, so eine Datenbank zu starten. Im Sinne von schnellen Testzyklen kann es also sinnvoll sein, bestimmte Tests mit einer In-Memory-Datenbank durchzuführen, die sich idealerweise ähnlich verhält wie die Produktionsdatenbank.

In weiteren Module- oder Integrationstest sollen aber auch die Konnektoren mit getestet werden, weswegen die entsprechenden Services mitlaufen müssen. Für einige dieser Services bietet das Anypoint-Studio mit Munit bestimmte Server-Komponenten an (Database, FTP).

Mule 3.9 liefert eine solche Datenbank als Bestandteil von Munit mit. Tatsächlich steckt dahinter eine H2-Datenbank , die häufig verwendet wird, um schnelle Unit- oder Modultests mit einer quasi-echten-Datenbank auszuführen.

Der vollständige Code für die gesamte Artikelserie liegt in gitlab .

Modul-Tests mit In-Memory Datenbank

Installation des Datenbank-Moduls

Die MUnit-Tools liefern ein Modul (namespace dbserver), mit dem eine InMemory-Datenbank einfach in Tests integriert werden kann. Vom AnypointStudio aus kann dieses Modul über die Munit Update Site installiert werden:

Select DBServer in Munit-Update Site

Vorbereiten der Datenbank

Die eigentliche Anwendung verwendet einen generischen Datenbank-Konnektor, um die Datenbank anzusprechen (ich habe in der Anwendung eine Postgres-DB angenommen):

1<db:generic-config name="Generic_Database_Configuration"
2    url="${db.url}"
3    driverClassName="org.postgresql.Driver"
4    doc:name="Generic Database Configuration"/>

Ausgehend von dem Szenario aus dem ersten Artikel müssen die Tests ein wenig angepasst werden. Zunächst wird das Mocking der Konnektoren abgeschaltet. Das geschieht auf Ebene der Test-Suite:

1<munit:config name="munit" doc:name="MUnit configuration" mock-connectors="false" mock-inbounds="false"/>

Als nächstes müssen Test-Properties geladen werden, die für die Ausführung der Tests die Datenbank-Konfiguration definieren:

1<context:property-placeholder location="api.dbserver.properties" />

Diese Datei enthält die Einstellungen, um die In-Memory-Datenbank anzusprechen, sobald sie gestartet wurde. Es werden die Properties definiert, die in der DB-Konfiguration der Anwendung verwendet werden: db.url=jdbc:h2:mem:postgres

Als nächstes konfigurieren wir den Datenbankserver. Man kann den H2-Datenbankserver in verschiedenen Emulationsmodi laufen lassen. In diesem Fall benutzen wir den PostgreSQL-Modus. Zusätzlich wird ein SQL-File angegeben, das beim Starten ausgeführt wird. Ich verwende das in der Regel, um das Schema vorzubereiten und ggf. Daten zu laden, die für alle Tests gelten sollen.

1<dbserver:config name="DB_Server" database="postgres"
2    connectionStringParameters="MODE=PostgreSQL" doc:name="DB Server"
3    sqlFile="USERS.sql"/>

Für unsere Tests enthält USERS.sql folgenden Code:

1CREATE TABLE users (
2    id int8 NOT NULL,
3    username VARCHAR NOT NULL,
4    lastname VARCHAR NOT NULL,
5    firstname VARCHAR NULL
6);

Aus Performance-Gründen ist es sinnvoll, die Datenbank möglichst selten hochzufahren, zu starten und zu stoppen. Daher wird das in den Before- bzw. After-Phasen der Test-Suite erledigt:

1munit:before-suite name="get_users_id-test-suite-dbserverBefore_Suite"
2    description="Before suite actions">
3    <dbserver:start-db-server config-ref="DB_Server" doc:name="Start DB Server"/>
4</munit:before-suite>
5 
6<munit:after-suite name="get_users_id-test-suite-dbserverAfter_Suite" description="After suite actions">
7    <dbserver:stop-db-server config-ref="DB_Server" doc:name="Stop DB Server"/>
8</munit:after-suite>

Wenn mehrere Tests in einer Suite enthalten sind und auf dieselbe Datenbank zugreifen, nutze ich die Before-/After-Test-Abschnitte, um per SQL mit TRUNK oder DELETE die Datenbank auf einen definierten einheitlichen Zustand zu bringen:

1<munit:before-suite name="dbserverBefore_Suite" description="Start DB on Testsuite-startup">
2    <dbserver:start-db-server config-ref="DB_Server" doc:name="Start DB Server"/>
3</munit:before-suite>
4 
5<munit:after-suite name="dbserverAfter_Suite" description="Ater suite actions">
6    <dbserver:stop-db-server config-ref="DB_Server" doc:name="Stop DB Server"/>
7</munit:after-suite>
8 
9<munit:before-test name="dbserverBefore_Test" description="Before tests actions">
10    <dbserver:execute config-ref="DB_Server" sql="TRUNCATE TABLE users" doc:name="Trunc users"/>
11    <dbserver:execute config-ref="DB_Server" 
12        sql="INSERT INTO users (id, username, lastname, firstname) VALUES(1234, 'jdoe', 'Doe', 'John')"
13        doc:name="Insert user"/>
14</munit:before-test>

Implementierung der Unit-Tests

Mit einer „schnellen“ Datenbank im Hintergrund möchte ich zunächst zeigen wie, vergleichbar zur vollständig gemockten Datenbank, Unit-Tests aussehen können.

Für die Test des Happy-Path und user-not-found für den Flow-Under-Test get_users_id gilt: Das war es fast. Im Vergleich zur Version des Tests für die gemockte Datenbank muss lediglich das Mocking entfernt werden. Die Tests sehen jetzt also so aus:

1<munit:test name="get_users_idTest-happy-path" description="Happy-Path Test">
2    <set-variable variableName="id" value="#[1234]" doc:name="set id=1234"/>
3    <flow-ref name="get_users_id" doc:name="get_users_id"/>
4    <assert-object-equals:compare-objects expected-ref="#[getResource('user-expected.json').asStream()]"
5        doc:name="user is returned"/>
6</munit:test>
7 
8<munit:test name="get_users_idTest-user-not-found" description="Expects a NotFoundException"
9    expectException="org.mule.module.apikit.exception.NotFoundException">
10    <set-variable variableName="id" value="#[2]" doc:name="set id=2"/>
11    <flow-ref name="get_users_id" doc:name="get_users_id"/>
12</munit:test>

Ändern Tests Werte in der Datenbank und sollen diese Werte mit einem Assert geprüft werden, kann die dbserver-Operation validate-that verwendet werden. Es wird eine Query und das erwartete Ergebnis (als csv) angegeben. Da dabei allerdings lediglich die Ergebnisse als String verglichen werden, lohnt es sich, alle möglicherweise zufälligen aber relevanten Bedingungen (verwendete Spalten, Spaltenreihenfolge, Groß-/Kleinschreibung, etc.) explizit im Query-Statement zu spezifizieren. Für Details hierzu soll ein Verweis auf die Dokumentation reichen.

Implementierung der Integrationstests

Mit Tests zu prüfen, ob die Subflows funktionieren ist gut und schön. Allerdings ist damit nicht gewährleistet, dass die APIs auch so funktionieren wie erwartet. Deswegen sollten Integrationstests den End-2-End-Aufruf prüfen. Um ein komplettes Set an Tests für per RAML spezifizierte APIs zu erzeugen sei auf einen anderen Artikel verwiesen. Im Rahmen dieses Artikels unterscheiden sie sich nicht sehr stark von den Unit-Tests. Die Datenbank wird auf exakt dieselbe Art und Weise angesteuert, lediglich der Aufruf des Flow-Under-Test und das Prüfen des Ergebnis unterscheiden sich leicht:

1<http:request-config name="HTTP-APIKit" host="localhost" port="${http.port}" basePath="/api/" doc:name="HTTP Request Configuration">
2    <http:raml-api-configuration location="api.raml"/>
3</http:request-config>
4 
5<munit:test name="users-id-get:/users/{id}:apiConfigTest" description="Test apikit-flow happy-path">
6    <http:request config-ref="HTTP-APIKit" path="/users/{id}" method="GET" doc:name="HTTP">
7        <http:request-builder>
8            <http:uri-param paramName="id" value="1234"/>
9        </http:request-builder>
10    </http:request>
11    <munit:assert-on-equals expectedValue="#[200]" actualValue="#[message.inboundProperties['http.status']]"
12        doc:name="Assert http.status is 200"/>
13    <assert-object-equals:compare-objects expected-ref="#[getResource('user-expected.json').asStream()]"
14        doc:name="user is returned "/>
15</munit:test>
16 
17<munit:test name="users-id-get:/users/{id}:apiConfigTest-nouser" description="Test apikit-flow with missing user">
18    <http:request config-ref="HTTP-APIKit" path="/users/{id}" method="GET" doc:name="HTTP">
19        <http:request-builder>
20            <http:uri-param paramName="id" value="2"/>
21        </http:request-builder>
22        <http:success-status-t-validator values="404"/>
23    </http:request>
24    <munit:assert-on-equals expectedValue="#[404]" actualValue="#[message.inboundProperties['http.status']]"
25        doc:name="Assert http.status is 404"/>
26</munit:test>

Zusammenfassung

(M)Unit-Tests, die Datenbankzugriffe komplett mocken, ignorieren wesentliche Teile der zu testenden Mule-Anwendungen. Das ist einerseits vorteilhaft, weil so wirklich nur die gewünschte Logik getestet wird und Tests möglichst schnell ausgeführt werden sollen. Andererseits können so Fehler in der Konfiguration von Datenbank-Endpoints nicht gefunden werden.

In diesem zweiten Teil der Artikelserie haben wir gesehen, wie als Kompromiss eine (In-Memory)-Datenbank für eine Reihe von MUnit-Tests gestartet werden kann, so dass aus Mule-Sicht die echten Endpoints ausgeführt und mit getestet werden.

Ein Nachteil ist allerdings immer noch, dass die von Mule bereitgestellte In-Memory-Datenbank die spätere externe Datenbank lediglich simuliert und sich diese daher anders verhalten kann als die Datenbank in Produktion. Im Endeffekt müssen daher auch Tests gegen eine produktionsähnliche Datenbank ausgeführt werden. Dieser Aufgabe widmet sich der nächste Teil dieser Artikelserie.