Antwort.

Die Automatisierung von Tests begann historisch mit der Idee, die Geschwindigkeit zu erhöhen und den menschlichen Faktor bei Prüfungen zu reduzieren, jedoch stellte sich schnell heraus, dass automatisierte Tests oft bei jedem Durchlauf unterschiedlich reagieren. Wiederholbarkeit (Repeatability) und Determiniertheit sind grundlegende Anforderungen an die Qualität von Automatisierungstests, die unter denselben Bedingungen dasselbe Ergebnis liefern sollten.

Probleme entstehen aufgrund von nicht offensichtlichen Abhängigkeiten: instabilen Testdaten, unsynchronisierten Umgebungen, parallelen Prozessen oder externen Diensten. Dies führt zu flakigen Tests – ihre Ergebnisse sind nicht vorhersehbar.

Lösungen basieren auf strenger Kontrolle der Ausführungsumgebung, Testisolierung, Mock-/Stub-Objekten, statischen Daten und reproduzierbaren Szenarien (z. B. das Bereinigen und Vorbereiten der Datenbank vor jedem Test).

Wichtige Merkmale:

Kontrolle der Testdaten und vorhersehbare Initialisierung der Testumgebung.
Isolation der Tests voneinander und Verzicht auf intertestliche Abhängigkeiten.
Verwendung von Mock-/Stub-Objekten zur Arbeit mit instabilen oder externen Diensten.

Fallenfragen.

Was tun, wenn ein flakiger Test nur in der CI auftritt, während lokal alles stabil ist?

Dies ist fast immer mit Unterschieden in den Umgebungen verbunden: Versionen von Abhängigkeiten, Geschwindigkeit der Infrastruktur, Parallelität, OS-Einstellungen oder Reihenfolge der Testausführung. Die Lösung besteht darin, die CI-Umgebung so nah wie möglich an die Entwicklungsmaschine anzupassen (Docker, gleiche Seed-Werte, SetUp/TearDown in Tests einstellen).

Kann man parametrisierten Tests volle Determiniertheit zusprechen, wenn die Daten aus der Datenbank stammen?

Nein. Selbst wenn die Daten grundsätzlich übereinstimmen, kann sich die DB zwischen den Tests oder zwischen Releases ändern. Für echte Determiniertheit sollten die Daten in jedem Test explizit vorbereitet und bereinigt werden.

Wenn man sleep verwendet, um auf das Laden von Elementen zu warten, löst das das Problem der Instabilität von UI-Tests?

Nein. Sleep maskiert nur das Problem und verlangsamt den Testablauf. Es sollte korrekt mit expliziten Wartezeiten (Explicit Waits) gearbeitet werden, die auf spezifische Bedingungen warten, anstatt auf eine feste Zeit.

Typische Fehler und Antipatterns

Verwendung von "magischen" Zahlen und Verzögerungen anstelle von korrekter Synchronisation.
Intertestliche Abhängigkeiten oder Umweltzustandsänderungen, die zwischen den Tests nicht zurückgesetzt werden.
Vermischung von Testdaten zwischen Szenarien.

Beispiel aus der Praxis

Negativer Fall

Im Projekt wurden UI-Tests auf einer Testumgebung durchgeführt, die nach manuellen Tests nicht bereinigt wurde. Alle paar Nächte fielen die Tests mit "zufälligen" Fehlern aus, die lokal nicht auftraten. Das Team fügte sleep zu den Tests hinzu und ignorierte die flakigen Probleme.

Vorteile:

Man musste nicht viel Zeit mit der Ursachenfinderarbeit verschwenden.
Die Tests konnten manchmal dennoch Bugs aufdecken.

Nachteile:

Zeitaufwand für die Wiederholungen.
Falsche negative Ergebnisse demotivierten die Ingenieure.
Die Berichte waren mit Rauschen überlagert, echte Regressionen konnten übersehen werden.

Positiver Fall

Nach dem Eintritt eines erfahrenen DevOps-Ingenieurs implementierte das Team Skripte zur Rücksetzung und Initialisierung der Testdaten, fügte Mock-Services für instabile Integrationen hinzu und begann, die Tests in Containern auszuführen. Flaky-Tests verschwanden nahezu vollständig.