Antwort

Geschichte der Frage:

Die Automatisierung von Tests ist eng mit der Notwendigkeit verbunden, vorhersehbare und reproduzierbare Testdaten zu erstellen und zu pflegen. Manuelle Tests können beliebige Daten verwenden, aber automatisierte Szenarien erfordern eine genaue Kontrolle über den Zustand der Daten in der Datenbank oder der Umgebung. Der Umfang der Anwendungen, die Arbeit mit Mikrodiensten und die Anforderungen an die Vertraulichkeit haben die Aufgabe der Verwaltung von Testdaten noch komplizierter gemacht.

Problem:

Ohne verwaltete Testdaten werden Tests instabil und ihre Ergebnisse sind nicht repräsentativ. Oft gibt es Situationen, in denen:

Tests aufgrund von Änderungen in der Datenbank fehlschlagen
Daten von mehreren Tests gleichzeitig verwendet werden
Kollisionen und komplexe Abhängigkeiten auftreten

Darüber hinaus kann die Verwendung realer Daten die Sicherheit oder Datenschutzrichtlinien verletzen.

Lösung:

Moderne Ansätze umfassen:

Vorbereitung von "Fixtures" (Datenmengen, die vor dem Test geladen und nach dem Test entfernt werden)
Generierung von einzigartigen Testdaten on-the-fly
Verwendung von separat zugewiesenen Testumgebungen
Moquing oder Stubs für externe Dienste
Anwendung von Werkzeugen für Migration und Rollback von Daten (z.B. Liquibase, Flyway)

Wesentliche Merkmale:

Möglichkeit, den Zustand der Umgebung vollständig zu kontrollieren
Schnelles Wiederherstellen der Daten auf den Referenzzustand
Verwendung spezialisierter Speicher für Testdaten

Trickfragen.

Kann man reale Daten aus der Produktionsumgebung für automatisierte Tests verwenden?

Nein. Das kann zu Datenlecks, Verletzungen von Vorschriften sowie zu instabilen Tests aufgrund ständiger Änderungen im Produktionstsystem führen.

Hilft es, einfach alle Daten zwischen den Tests zu bereinigen, um Stabilität beim Testen zu garantieren?

Nein. Es ist wichtig, die Daten nicht nur zu bereinigen, sondern sie auch richtig auf den benötigten Zustand vorzubereiten. Außerdem kann eine Massenbereinigung parallellaufende Tests oder Dienste beeinträchtigen.

Reicht es aus, eine einzige Testumgebung für alle Teams zu haben?

Nein, das ist der Weg zu Kollisionen und Konflikten zwischen den Tests verschiedener Teams. Optimal sind isolierte Umgebungen oder Containerisierung (Docker-Test-Suiten, temporäre Umgebungen).

Typische Fehler und Anti-Patterns

Automatisierung mit "Live"-Daten
Fehlende Bereinigung und Vorbereitung der Umgebung
Verwendung derselben Daten in parallelen Tests

Beispiel aus der Praxis

Negativer Fall

Das Testteam verwendete eine einzige Testdatenbank, in der sowohl automatisierte als auch manuelle Tests arbeiteten. Häufig fielen automatisierte Tests aufgrund von manuellen Datenlöschen oder -änderungen aus, was zu langwieriger Fehlersuche und Zeitverlust führte.

Vorteile:

Minimale Infrastrukturkosten
Einfacher Zugang zu allen Daten

Nachteile:

Instabilität der Tests
Häufige "defekte" Umgebungen
Schwierige Analyse der Ursachen für Testausfälle

Positiver Fall

Das Unternehmen implementierte eine Infrastruktur mit temporären Umgebungen: Jeder Test wurde auf einer separaten Kopie der Datenbank ausgeführt, die über Docker bereitgestellt wurde. Fixtures wurden automatisch über Migrationsskripte geladen.