Was sind eigentlich Flaky Tests?

Flaky-Tests sind definiert als Tests, die sowohl erfolgreiche als auch fehlgeschlagene Durchläufe haben, obwohl keine Änderungen am Code oder am Test selbst vorgenommen wurden. Unzuverlässige Testergebnisse können durch mehrere Faktoren bedingt sein, z. B. Inkonsistenzen in der Testumgebung, kein Zurücksetzen der Testdaten zwischen den Testläufen, Zeit- und Zeitzonenprobleme und Abhängigkeiten von der Reihenfolge der Testausführung. – Quelle: https://www.jetbrains.com/de-de/teamcity/ci-cd-guide/concepts/flaky-tests/

Und hier:

Das Problem von Flaky-Tests besteht darin, dass sie Ihre CI/CD-Pipeline verlangsamen und das Vertrauen in Ihre Testprozesse untergraben. Da auf die Ergebnisse von Flaky-Tests kein Verlass ist, können Sie sich nicht sicher sein, ob ein erfolgreicher Testlauf tatsächlich bedeutet, dass Ihr Code fehlerfrei ist, und ob Sie bei einem fehlgeschlagenen Test Zeit investieren sollten, um das Problem zu reproduzieren und zu beheben.

Um Flaky-Tests zu erkennen, müssen Sie die Testergebnisse mehrerer Testläufe vergleichen. Bei manueller Durchführung wäre diese Analyse sehr zeitaufwändig, aber zum Glück können viele CI-Server Flaky-Tests automatisch erkennen.

Wenn Sie Flaky-Tests in den Griff bekommen möchten, besteht der erste Schritt darin, sie zu erkennen. Sobald das Ausmaß des Problems bekannt ist, können Sie eine Prioritätenfolge für die Behebung festlegen. In der Zwischenzeit sollten Flaky-Tests stummgeschaltet werden, um unzuverlässige Testergebnisse aus automatisch erstellten Testberichten auszuschließen. – Quelle: https://www.jetbrains.com/de-de/teamcity/ci-cd-guide/concepts/flaky-tests/

Das ist der allgemeine Ansatz, den ich bevorzugen würde, weil wir das in verschiedenen Projekten umgesetzt haben:

1. Messung der Fehleranfälligkeit, um instabile Tests zu identifizieren. Eine Möglichkeit besteht darin, verdächtige Tests aus der Hauptimplementierungspipeline in die Quarantäne zu verschieben, die Ausführung dieser Tests unter denselben Umgebungsbedingungen mehrfach zu wiederholen und Tests auszuwählen, die gemischte Ergebnisse liefern (siehe Martin Fowlers Eradicating Non-Determinism in Tests).
2. Behebt den schlechten Test-Code. Dies umfasst die Beseitigung offensichtlicher Fehler und die Änderung des Testdesigns.
   1. Offensichtliche Fehler in Tests beziehen sich auf: fehlende Isolation, asynchrones Verhalten, Remote Service, Zeitprobleme, Ressourcenlecks und globale Zustände. Siehe Martin Fowler’s Eradicating Non-Determinism in Tests für eine Erklärung dieser Probleme. Eine detailliertere Analyse der Ursachen und möglicher Abhilfemaßnahmen findet sich auch in der wissenschaftlichen Arbeit An Empirical Analysis of Flaky Tests.
   2. Zu den Anti-Patterns im Testdesign gehört die umgekehrte Testpyramide, bei der sich das Team hauptsächlich auf End-to-End-Tests verlässt und nur wenige Integrationstests und noch weniger Unit-Tests verwendet. End-to-End-Tests sind in der Regel nicht nur weniger stabil (und damit weniger zuverlässig), sondern auch langsamer und schwieriger bei der Isolierung von Fehlerursachen. Weitere Einzelheiten hierzu finden Sie im Google Testing Blog unter Just Say No to More End-to-End Tests.
   3. Es gibt auch Hinweise darauf, dass je größer der Test ist, desto wahrscheinlicher ist es, dass er fehlerhaft ist. Außerdem korrelieren bestimmte Tools mit einer höheren Rate an fehlerhaften Tests. Zum Beispiel haben WebDriver-Tests (egal ob in Java, Python oder JavaScript geschrieben) den Ruf, fehlerhaft zu sein (siehe Where do our flaky tests come from? im Google Testing Blog). Gängige Lösungen für diese Probleme sind: weniger im Test machen, von Out-of-Proc zu In-Proc wechseln und von End-to-End zu Komponenten- und Unit-Tests wechseln (siehe Winning with Flaky Test Automation von Microsoft für eine Erklärung dieser Lösungen).
3. Verwendet flaky Tests zur Fehlererkennung. Automatisierte Tests dienen zwei Zwecken: der Gateway-Kontrolle und der Suche nach neuen Fehlern. Bei der Gateway-Kontrolle geht es darum, zu überprüfen, ob ein Commit eingefügt, ein Build in einer Testumgebung bereitgestellt oder ein Produkt freigegeben werden kann. Die Gateway-Kontrolle erfordert stabile und schnelle Tests. Instabile End-to-End-Tests sind hier nicht geeignet, obwohl sie mehr Fehler finden können. Ihre Ergebnisse erfordern jedoch eine gründlichere Analyse, da, wie OP feststellte, viele mit unbeständigen Tests gefundene Fehler falsch positiv sein können. In Winning with Flaky Test Automation von Microsoft werden Einzelheiten dieser Technik erörtert.