Deine automatisierte Suite fällt zufällig in etwa fünf Prozent der Läufe durch. Wie gehst du mit flaky Tests um?

Zuerst in Quarantäne, damit die Suite wieder vertrauenswürdig ist, dann die Grundursachen beheben statt sie mit Retries zu übertünchen. Die üblichen Ursachen sind Timing und Synchronisation (feste Sleeps, Races), geteilte oder übrig gebliebene Testdaten, Abhängigkeit von der Ausführungsreihenfolge und instabile Umgebungen. Behoben wird das, indem du auf Bedingungen statt auf Dauern wartest, Daten pro Test isolierst und jeden Test unabhängig von der Reihenfolge machst.

Als Erstes stoppe ich die Blutung, denn eine Suite, die zufällig fehlschlägt, wird ignoriert, und sobald Leute sie ignorieren, hast du gar kein Sicherheitsnetz mehr. Flaky Tests kommen also in einen separaten Lauf, der die Pipeline nicht blockiert, mit Ticket und Verantwortlichem, nicht gelöscht und nicht still für immer wiederholt. Dann diagnostiziere ich sie wirklich. Der mit Abstand größte Topf ist Synchronisation: jemand hat einen festen Sleep genutzt oder direkt nach einem Klick geprüft, während der Request noch unterwegs ist. Der Fix ist, auf eine Bedingung zu warten, also darauf, dass das Element bedienbar ist oder der Netzwerkaufruf durch ist, nie auf eine Dauer. Zweiter Topf sind Daten: zwei Tests, die denselben Account nutzen, oder ein Test, der einen leeren Zustand annimmt, den der vorige Lauf verschmutzt hat. Das behebe ich, indem ich Daten pro Test mit eindeutiger Kennung anlege. Drittens die Reihenfolgeabhängigkeit, die ich rausspüle, indem ich die Suite absichtlich in zufälliger Reihenfolge laufen lasse. Und ich verfolge die Flake-Rate auf einem Dashboard, denn was nicht gemessen wird, schleicht sich zurück. Alles über etwa einem Prozent behandle ich als echtes Problem.