Kurzlebige Datenbanken in Containern für Integrationstests

Ziel

Datenzugriffs- und Integrationstests gegen die echte, für den Lauf frisch gestartete Datenbank-Engine ausführen, damit Tests Dialekt-, Constraint- und Transaktionsverhalten erfassen, das ein In-Memory-Ersatz oder ein gemocktes Repository verdeckt.

Voraussetzungen

Eine Container-Laufzeitumgebung auf Entwicklerrechnern und in der CI; Migrationen, die sich mit einem einzigen Befehl von Grund auf anwenden lassen; Tests, die Verbindungseinstellungen aus der Konfiguration lesen, statt einen festen Port oder eine bereits vorhandene Datenbank vorauszusetzen.

Schritte

1. Die Engine einmal pro Testlauf starten, nicht pro Test. Testcontainers beschreibt sich selbst als Anbieter leichtgewichtiger, wegwerfbarer Datenbank-Instanzen in Docker-Containern, die aus dem Testcode gestartet und danach entfernt werden; die einfache Alternative ist docker run mit einem zufälligen veröffentlichten Port, der zur Laufzeit zurückgelesen wird.
2. Das Datenverzeichnis auf ein tmpfs-Mount legen (--tmpfs bei docker run) und die Durability-Einstellungen der Engine für den Nicht-Produktionseinsatz lockern, da die Daten ohnehin wegwerfbar sind.
3. Migrationen einmal auf eine Vorlagendatenbank anwenden. Die PostgreSQL-Dokumentation hält fest, dass CREATE DATABASE durch Kopieren einer bestehenden Datenbank funktioniert, sodass CREATE DATABASE t_42 TEMPLATE t_base jeder Testdatei eine frische Kopie liefert, ohne die Migrationen erneut auszuführen. Die Quelldatenbank darf während des Kopierens keine weiteren Verbindungen haben.
4. Eine Isolationsstrategie wählen und sie überall anwenden: eine frische Datenbank pro Testdatei, eine Transaktion pro Test, die zurückgerollt wird, oder das Leeren (Truncate) der von einem Test berührten Tabellen.
5. Verbindungseinstellungen aus dem laufenden Container erzeugen und über denselben Konfigurationsweg übergeben, den die Anwendung auch in der Produktion nutzt, sodass der Test auch die Konfigurationsverarbeitung abdeckt.
6. Den Image-Tag auf die Hauptversion der Produktion festnageln und lokal wie in der CI denselben Aufbau verwenden.

Erwartetes Ergebnis

Tests durchlaufen den echten Query-Planer, die echten Constraints, Isolationsstufen und Erweiterungsfunktionen; ein grüner Lauf bedeutet, dass Schema und Abfragen übereinstimmen, und eine Migration, die eine Abfrage bricht, schlägt schon vor dem Deployment fehl.

Grenzen und Prüfbasis

Der Start fügt jedem Lauf Sekunden hinzu, daher reine Unit-Tests in einer separaten, schnelleren Suite halten. Testcontainers dokumentiert die Wiederverwendung eines Containers über mehrere Läufe hinweg als experimentelles Opt-in-Feature, das für den CI-Einsatz nicht geeignet ist. Eine zurückgerollte Transaktion kann keinen Code testen, der committet, mehrere Verbindungen nutzt oder sich auf Trigger verlässt, die beim Commit auslösen. Eine verwaltete Cloud-Datenbank kann sich vom Image in Erweiterungen und Parametern unterscheiden; diese Methode testet die Engine, nicht den verwalteten Dienst. Es werden keine Zeitangaben behauptet.