Echte Eigenschaften statt bequemer Ersatzsysteme
SQL-Dialekte, Transaktionsverhalten und Indizes unterscheiden sich. Ein Test gegen dieselbe Datenbankfamilie kann Probleme sichtbar machen, die eine reine In-Memory-Lösung übersieht. Die Container werden aus festgelegten Images gestartet und nach dem Test entfernt. Voraussetzung ist eine geeignete Containerlaufzeit; deren Bereitstellung muss auch in CI geklärt sein.
Startbereitschaft und Datenzustand kontrollieren
Ein gestarteter Prozess ist nicht zwingend schon ansprechbar. Tests sollten auf einen passenden Bereitschaftszustand warten. Anschließend werden Schema und Daten gezielt eingerichtet. Gemeinsame Datenbankcontainer können Laufzeit sparen, verlangen aber saubere Isolation. Sonst hängt das Ergebnis wieder von der Reihenfolge der Tests ab.
Realistisch heißt nicht identisch
Ein einzelner Container bildet keinen produktiven Cluster mit Netzwerklatenz, Failover und mehreren Mandanten ab. Testcontainers ist deshalb besonders wertvoll für Integrationsverhalten einzelner Abhängigkeiten. Performance- und Wiederanlauftests benötigen ergänzende Umgebungen. Auch Imageversionen und Sicherheitsupdates gehören in die Pflege des Testaufbaus.
Beispiel: Eine Datenbankmigration absichern
Ein Test startet die unterstützte Datenbankversion, spielt das bisherige Schema mit repräsentativen Daten ein und führt die neue Migration aus. Danach prüft er Datenbestand, Abfragen und notwendige Einschränkungen. Damit wird eine Änderung am Schema vor dem Deployment nachvollziehbar getestet, statt erst auf einem gemeinsam genutzten Testserver aufzufallen.
Womit Sie sinnvoll beginnen können
- Containerimages nachvollziehbar versionieren.
- Daten und Lebenszyklus der Testabhängigkeiten explizit festlegen.
- Grenzen zu Cluster-, Last- und Wiederanlauftests dokumentieren.