Wer Integrationstests gegen echte Datenbanken fährt, kennt Testcontainers: Für die Dauer eines Testlaufs startet die Bibliothek echte Dienste als Container — Datenbanken, Broker, HTTP-Attrappen. Der Test spricht mit derselben Software wie die Produktion, nur kurzlebig und auf einem zufälligen Port. Mit Version 2 ändern sich allerdings Namen, an denen jeder bestehende Test hängt.
Artefakt und Paket heißen anders
Alle Module tragen jetzt das Präfix testcontainers- im Artefaktnamen, und die
Containerklassen liegen in modulspezifischen Paketen. Aus dem Modul postgresql
wird testcontainers-postgresql, und die Klasse zieht von
org.testcontainers.containers nach org.testcontainers.postgresql um. Die
Gruppe bleibt gleich — geändert haben sich Artefaktname und Paket, nicht der
Hersteller. Bleibt der alte Import stehen, findet der Build die Klasse schlicht
nicht mehr.
Ebenfalls neu: Die direkte Unterstützung für JUnit 4 ist mit 2.0 entfallen.
Ein alter Test mit ClassRule lässt sich nicht mehr übersetzen.
Warum Attrappen still danebenliegen
Der Aufwand lohnt, weil In-Memory-Datenbanken an genau den Stellen abweichen, die später wehtun: eigener SQL-Dialekt, anderes Transaktionsverhalten, Migrationen mit datenbankspezifischem SQL, die in der Attrappe gar nicht laufen. Grün heißt dort „syntaktisch möglich”, nicht „so wird es laufen”.
Die Startzeit ist nicht das Problem
Der häufigste Einwand ist die Laufzeit — und er beruht meist auf einem Fehler im Aufbau. Die Startzeit fällt einmal je Testklasse an, nicht je Test. Wer das Container-Feld nicht statisch deklariert, startet die Datenbank für jede Testmethode neu; aus Sekunden werden dann vierzig Minuten.
Mehr dazu im Seminar
Einrichtung, Wartestrategien und die Fehleranalyse über Container-Logs zeigt das Modul Testcontainers 2 einrichten und verwenden — inklusive Video und Kapitelübersicht.