Flaky Test

Ein Flaky Test liefert auf demselben Commit unterschiedliche Ergebnisse. Lassen Sie ihn zehnmal gegen unveränderten Code laufen, und Sie erhalten einige Erfolge und einige Fehlschläge. Das entscheidende Merkmal: Am Produkt hat sich nichts geändert – die Schwankung kommt vom Test, seinen Daten oder seiner Umgebung.

Warum das wichtig ist

Eine Suite mit ein paar Flaky Tests bringt dem Team bei, Fehlschläge so lange neu zu starten, bis sie grün werden. Hat sich diese Gewohnheit eingeschliffen, werden auch echte Regressionen „weggeklickt“. Flakiness verlangsamt außerdem Pipelines, weil Retries die Laufzeit vervielfachen, und untergräbt das Vertrauen in die Automatisierung schneller als fehlende Abdeckung.

Häufige Ursachen

• Timing. Der Test handelt, bevor Seite oder API bereit sind: ein fester sleep, eine Prüfung, die einen Wert einmal liest, statt es erneut zu versuchen, oder eine noch laufende Animation.
• Geteilter Zustand. Zwei Tests schreiben denselben Nutzer, denselben Warenkorb oder dieselbe Datenbankzeile. Einzeln bestehen sie, parallel oder in anderer Reihenfolge schlagen sie fehl.
• Abhängigkeit von der Testreihenfolge. Ein Test verlässt sich auf Daten, die ein früherer Test angelegt hat.
• Umgebung. Langsame oder geteilte Testumgebungen, Drittanbieter-Services, Rate Limits, Zeitzonen und Zeitumstellungen.
• Nicht deterministische Daten. Zufällige Eingaben ohne protokollierten Seed oder Assertions auf „jetzt“.

Wie man damit umgeht

1. Reproduzieren Sie ihn. Führen Sie den einzelnen Test in einer Schleife aus (Playwright: npx playwright test my.spec.ts --repeat-each=20) und zeichnen Sie einen Trace oder ein Video eines fehlgeschlagenen Laufs auf.
2. Finden Sie die Ursache, statt einen Retry hinzuzufügen. Ersetzen Sie Sleeps durch bedingungsbasierte Waits, etwa Web-First-Assertions in Playwright oder WebDriverWait in Selenium. Geben Sie jedem Test seine eigenen Daten.
3. Stellen Sie ihn unter Quarantäne, wenn Sie ihn heute nicht beheben können. Nehmen Sie ihn aus dem blockierenden Gate und verschieben Sie ihn in einen nachverfolgten, nicht blockierenden Job mit einem Owner, damit das Hauptsignal vertrauenswürdig bleibt.
4. Verfolgen Sie die Flake-Rate über die Zeit. Erfolgreiche Retries verbergen das Problem, solange der Report sie nicht ausweist.

Retries (retries: 2 in playwright.config.ts) sind in der CI ein vernünftiges Sicherheitsnetz, aber ein Test, der nur im Retry besteht, ist trotzdem flaky. Playwright weist solche Tests als „flaky“ aus, damit Sie sie sehen.