Datenbanken testen mit Testcontainers in Mule4

Hier erfährst du die Möglichkeiten Testcontainers in Mule4 zu nutzen, um deine Datenbankaufrufe zu testen.

Vor einiger Zeit hat mein Kollege Christian Langmann eine Blogartikelserie veröffentlicht, in welcher er aufzeigt, wie man in Mule3 Munit-Tests schreiben kann, um Datenbankaufrufe zu validieren. In seinem letzten Teil der Serie geht er auf das Testen mit Docker ein und zeigt, wie das Plugin MUnit-Db-Testcontainers-Connector in Munit eingebunden werden kann.

Der Nachteil ist, dieses Plugin unterstützt ausschließlich Mule3 und eine Unterstützung für Mule4 ist nicht geplant. Auch wegen der Architektur und wie das Classloading in Mule4 umgesetzt sind, ist eine Erweiterung des bestehenden Plugins nicht möglich.

Wie teste ich Datenbanken in Mule4?

Um Datenbankaufrufe mit Testcontainers zu testen, ist in Java nicht viel zu tun. Vorausgesetzt alle Abhängigkeiten für Testcontainers sind in der pom.xml hinterlegt, muss nur die Konfiguration für JDBC angepasst werden. Dafür ist es nötig den „driver class name“ mit org.testcontainers.jdbc.ContainerDatabaseDriver und die URL mit, zum Beispiel, jdbc:tc:postgresql:///postgresql zu setzen. Folgende Bean startet dann die Datenbank und beendet diese, wenn der Test beendet ist.

1public class TestContainerRunner {
2    private Connection connection;
3    private String url;
4    
5    public void initialise() throws SQLException, IOException {
6        Properties props = System.getProperties();
7        props.load(this.getClass().getClassLoader().getResourceAsStream("munit.properties"));
8        this.url = (String )props.get("db.url");
9    
10        ContainerDatabaseDriver driver = new ContainerDatabaseDriver();
11         this.connection = driver.connect(this.url, new Properties());    
12    }
13
14    public void destroy() throws SQLException { 
15        this.connection.close();
16         ContainerDatabaseDriver.killContainer(this.url);
17    }
18}

Der Vorteil des Startens von Testcontainers mittels einer Bean ist, dass der MUnit-Test frei von Testcontainer-spezifischen Dingen ist. Der MUnit-Test wird somit leichter zu lesen. Der große Nachteil ist, dass wir die Properties nicht über einen Property-Provider von Mule laden lassen können und das Auslesen der Properties selber programmiert werden muss. Das kann beliebig kompliziert sein, wenn statt properties files, yaml oder json verwendet wird. Eine Lösung für dieses Problem wäre, die beiden Methoden als static umzusetzen und die URL als Parameter zu übergeben. Die Connection müsste außerdem Threadsafe gekapselt werden. In MUnit könnte dann über den „invoke static“-Connector das Starten und Stoppen des Testcontainers gesteuert werden. Das funktioniert für genau einen Testcontainer mit einer Datenbank! Möchten wir nun mehrere Datenbanken mit Testcontainers starten wird das eine sehr komplexe Aufgabe und diese Umsetzung ist nicht zu empfehlen.

Mule-Testcontainers-Db eilt zur Rettung

Wie anfangs erwähnt kann das Testcontainers-Plugin für Mule3 nicht aktualisiert werden und die Umsetzung ohne Plugin ist schlecht erweiterbar. Aus diesem Grund habe ich ein neues Plugin geschrieben, um Mule4 zu unterstützen und die oben genannten Nachteile zu umgehen. Folgendes Bild zeigt, wie man das Plugin verwenden kann. Es empfiehlt sich das Starten des Testcontainers im Before Suite Flow durchzuführen und anschließend mit normalen Mule-Bordmitteln das Datanbankschema zu erstellen. Pro MUnit-Test kann die Datenbank in einen initialen Zustand versetzt werden, in dem der Before Test Flow verwendet wird. Sind alle Tests beendet, wird der After Suite Flow aufgerufen und der Testcontainer beendet. Die Konnektoren Start test containers und Stop test containers teilen sich eine Konfiguration, in der die JDBC URL hinterlegt ist. Möchte man also mehrere Datenbanken starten, braucht man lediglich mehrere Konfigurationen. Wie genau das Plugin verwendet wird, ist auf Github beschrieben.

Fazit

Datenbankaufrufe testen in Mule4 ist nicht mehr auf Mocks und die H2-In-Memory-Datenbank beschränkt. Durch Testcontainers haben wir die Möglichkeit, Datenbankaufrufe gegen eine echte Datenbank zu testen, die auch in Produktion verwendet wird. Ein Beispielprojekt für Mule4 ist auf Github, im Branch plugin veröffentlicht.