Antwort.

Flaky-Tests sind Tests, die bestehen oder fehlschlagen können, ohne dass sich der Code ändert, aufgrund zufälliger externer Faktoren. Sie untergraben das Vertrauen in die Automatisierung und erschweren CI/CD-Prozesse.

Geschichte der Frage: Die Problematik mit flaky Tests entstand mit dem Aufkommen zahlreicher E2E-, Integrations- und UI-Tests, als die Stabilität der Umgebung und abhängiger Dienste nicht garantiert war. Zunächst wurden solche Ausfälle ignoriert oder "manuell neu gestartet".

Problem:

Flaky-Tests machen die automatische Testausführung unzuverlässig.
Entwickler beginnen, echte Ausfälle zu übersehen und halten sie für falsch-positive.
Die Wartungszeit für Tests wächst und es wird manuelle Analyse der instabilen Ergebnisse benötigt.

Lösung:

Separate Erfassung von flaky Tests. Kennzeichnung (z. B. @FlakyTest) oder in eine separate Kategorie verschieben.
Automatisches Wiederholen. Im Falle eines Tests mit einem Fehler wird dieser X-mal wiederholt — wenn er nicht immer fehlschlägt, wird der Test als instabil markiert.
Analyse der Ursachen für Instabilität: Verwendung von Logs, Status-Snapshots, Ressourcenüberwachung (z. B. instabile Netzwerke, Warteschlangen oder GC-Aktivitäten).
Schrittweise Behebung: Arbeiten mit der Testumgebung, Vereinfachung von Szenarien, Mocking instabiler Abhängigkeiten.

Beispielcode für Auto-Retry:

import pytest
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_random_fail():
    ... # Testcode

Wichtige Merkmale:

Es ist wichtig, flaky Tests von echten Fehlern zu trennen.
Man sollte nicht einfach "alles wiederholen" — echte Bugs sollten nicht übersehen werden.
Der Status des Tests sollte regelmäßig analysiert und dokumentiert werden, nicht verschwiegen.

Fangfragen.

Sind flaky Tests immer ein Problem der Infrastruktur?

Nein, flaky Tests können durch Fehler in der Geschäftslogik, Rennen im Code, Asynchronität oder falsche Zeitbehandlung verursacht werden.

Reicht es aus, gescheiterte Tests einfach neu zu starten?

Nein, Retries maskieren nur das Problem. Man muss die Ursache suchen und beheben.

Sollte man alle instabilen Tests löschen?

Nein, sie sollten vorübergehend isoliert und die Ursachen behoben werden, anstatt sie einfach dauerhaft auszuschließen.

Typische Fehler und Anti-Patterns

Ignorieren von flaky Tests, was zu übersehenen schwerwiegenden Bugs führt.
Massenhaftes Wiederholen ohne Ursachenanalyse.
Kennzeichnung wichtiger Tests als flaky, ohne deren Behebung.

Beispiel aus dem Leben

Negativer Fall

In einem Projekt wurden flaky Tests einfach markiert und nicht mehr angefasst, da das Problem als "unlösbar" angesehen wurde.

Vorteile:

Reduzierung der Anzahl von falschen "roten" Builds.

Nachteile:

Echte Bugs gehen in Produktion.
Ständige manuelle Überprüfung der Ergebnisse.

Positiver Fall

Für jeden instabilen Test wurde ein automatischer Retry und eine interne Erfassung der Instabilität eingeführt. Es wurden regelmäßige gemeinsame Überprüfungen der Ursachen durchgeführt und Bugs behoben, sobald sie auftraten.