Was sind Flaky Tests?
Ein flaky test ist ein Test, der bei einem Durchlauf besteht und beim nächsten fehlschlägt, obwohl sich am zugrunde liegenden Code nichts geändert hat. Solche inkonsistenten Ergebnisse entstehen meist durch nicht-deterministisches Verhalten in der Anwendung oder im Testumfeld. Häufige Ursachen sind:
- Tests, die von der Ausführungsreihenfolge abhängen
- Tests, die mit Elementen interagieren, bevor die Seite vollständig geladen ist
- Race Conditions oder Timing-Probleme
Auf den ersten Blick scheint es am einfachsten, einen flaky Test einfach erneut auszuführen. Es gibt sogar Tools, die Tests bei einem Fehlschlag automatisch wiederholen. Aber ist das wirklich eine Lösung oder verschiebt man damit nur das eigentliche Problem?
Kurzfristiger Gewinn, langfristiger Schaden
Man könnte argumentieren, dass das Ignorieren von flaky Tests Zeit spart. Das Beheben kostet Zeit, und Deadlines sind knapp. Genau hier greift der sunk cost fallacy: Je mehr Zeit man damit verbringt, fehlgeschlagene Tests erneut auszuführen, desto eher glaubt man, dass dieses Verhalten akzeptabel oder gar normal sei.
Mit der Zeit wird die Test-Suite immer langsamer und unübersichtlicher. Man beginnt, jeden Fehler zu hinterfragen:
Ist das ein echter Bug oder nur wieder ein flaky Test?
Man startet den Test neu. Er besteht. Man macht weiter. Das Vertrauen in die Test-Suite sinkt, und man beginnt, wieder verstärkt manuell zu testen.
Das eigentliche Problem tritt zutage
Diese Strategie bricht vollständig zusammen, sobald mehrere flaky Tests auftreten. Egal wie oft man die Test-Suite erneut ausführt: Einer der Tests schlägt immer fehl, nur ist es jedes Mal ein anderer.
Das Team ist nun darauf trainiert, Fehler zu ignorieren, statt sie zu beheben. Die eigentlichen Ursachen werden nicht gelöst, sondern unter Wiederholungen und Workarounds begraben. Irgendwann ist die CI-Pipeline unzuverlässig, und das Team verbringt Stunden mit dem Beheben scheinbar zufälliger Fehler.
Besonders problematisch bei Kontextwechseln
Flaky Tests blockieren oft Aufgaben, die mit dem Test selbst nichts zu tun haben. Man will ein Feature abschliessen oder einen Bug beheben, doch ein nicht verwandter Test schlägt fehl, und man kann nicht mergen. Man wird gezwungen, in fremden Code einzutauchen, nur um Probleme zu lösen, die man zuvor ignoriert hatte. Dieser Kontextwechsel ist teuer, besonders wenn der Test von jemand anderem geschrieben wurde und man sich erst alle Zusammenhänge wieder erarbeiten muss.
Es gibt einfache Lösungen
Die meisten flaky Tests sind Systemtests. Diese simulieren Benutzerverhalten im Browser und sind empfindlich gegenüber Ladezeiten und Timing. Zum Glück lassen sich einige Probleme leicht beheben.
Ein Beispiel aus einem RSpec-Systemtest (Rails):
find("button.bg-danger", text: "Abmelden").click
expect(page).not_to have_content("Admin")
Dieser Test kann gelegentlich fehlschlagen, weil expect(page).not_to... ausgeführt wird, bevor der Logout-Vorgang abgeschlossen ist.
Eine robustere Variante sieht so aus:
find_button("Abmelden").click
expect(page).to have_content(I18n.t("devise.sessions.signed_out"))
expect(page).to have_no_content("Admin")
Hier wartet man zunächst auf die Erfolgsmeldung, bevor man prüft, ob der Benutzer ausgeloggt wurde. Dadurch werden Race Conditions vermieden und die Teststabilität verbessert.
Manche Probleme brauchen Zeit
Nicht jeder flaky Test ist einfach zu beheben. Manche erfordern tiefere Analysen, Abstimmungen im Team oder gezielte Recherchen. Wenn man diese Probleme ignoriert, statt sie zeitnah zu lösen, entsteht technische Schuld. Wenn das Problem Wochen später wieder auftaucht, ist es deutlich schwerer zu lösen, da man sich an die Details nicht mehr erinnert.
Fazit
Flaky Tests sind mehr als nur ärgerlich. Sie sind eine wachsende Belastung. Sie heute zu ignorieren, spart vielleicht Zeit, kostet aber morgen deutlich mehr. Je länger man die Behebung aufschiebt, desto aufwändiger und störender wird sie.
Wenn Ihre Test-Suite kein Vertrauen in die Software vermittelt, welchen Zweck erfüllt sie dann?
Beheben Sie flaky Tests frühzeitig. Lassen Sie sie sich nicht anhäufen. Behandeln Sie sie wie Bugs, denn genau das sind sie.