Richard Seidl
Unzuverlässige Tests zerstören das Vertrauen in KI-Systeme und verlängern Rückkopplungsschleifen, aber wenn du sie sofort löschst, verpasst du möglicherweise kritische Probleme in der Produktion. Unzuverlässige Tests deuten oft auf echte Probleme hin - vorübergehende Netzwerkfehler, Fehlerwirkungen oder Abhängigkeitsfehler -, mit denen der Produktionscode irgendwann konfrontiert wird. Zu den effektiven Strategien gehören der 100-fache Testlauf, bevor sie in den Build aufgenommen werden, das Führen einer separaten Blocklistendatei anstelle von verstreuten Ignoriervermerken und die Zuweisung individueller Verantwortlichkeiten, um sicherzustellen, dass fehlerhafte Tests behoben und nicht vergessen werden. Wenn ein Test trotz Untersuchung instabil bleibt, ist das Löschen eine gute Option - vor allem, wenn die zugrunde liegenden Risiken bereits durch kleinere, zuverlässigere Tests abgedeckt sind.
Podcast Episode: Warum dich deine CI-Pipeline anlügt
In dieser Folge spreche ich mit Simon Stewart, professioneller Softwareentwickler und ehemaliger Leiter des Selenium-Projekts seit über 10 Jahren, über eines der frustrierendsten Probleme beim Software-Testen: fehlerhafte Tests. Simon verrät, warum ein fehlerhafter Test nicht immer ein schlechter Test ist - manchmal birgt er sogar echte Risiken für die Produktion, die dein Team angehen muss. Wir beschäftigen uns mit praktischen Strategien für den Umgang mit fehlerhaften Tests in CI-Pipelines, von Gatekeeping-Techniken bei Meta bis hin zu der Frage, wann es in Ordnung ist, Tests zu löschen. Du erfährst, warum es wichtig ist, die Verantwortung einzelnen Personen (und nicht Teams) zuzuweisen, und wie du die Fehlerhaftigkeit von Tests als wertvolles Signal und nicht nur als Rauschen nutzen kannst.
"Ein fehlerhafter Test kann manchmal sogar ein guter Test sein, weil er Dinge aufzeigt." - Simon Stewart
Simon Stewart ist seit Beginn des neuen Jahrtausends als professioneller Softwareentwickler tätig. Er war über ein Jahrzehnt lang Leiter des Selenium-Projekts und ist Mitherausgeber der W3C-Spezifikationen für WebDriver und WebDriver Bidi.Neben der Browser-Automatisierung interessiert sich Simon auch für Monorepos, blitzschnelle, byteweise reproduzierbare Builds und die effiziente Skalierung der Softwareentwicklung. Er greift dabei auf seine Erfahrungen bei Open Source, ThoughtWorks, Google und Facebook zurück. Er war technischer Leiter des Build-Tool-Teams bei Facebook und arbeitet derzeit an Projekten mit Bazel, für das er mehrere Regelsätze pflegt.Simon lebt mit seiner Familie und seinem Hund in London.
Highlights der Episode
- Unzuverlässige Tests zerstören das Vertrauen in die KI und die Geschwindigkeit des Feedbacks; entferne sie sofort aus der Pipeline-Rotation.
- Flakiness offenbart oft echte Produktionsprobleme wie Race Conditions oder vorübergehende Fehlerwirkungen, die es zu beheben gilt.
- Weisen Sie unzuverlässige Tests Einzelpersonen und nicht Teams zu, sonst werden sie nie behoben.
- Meta führt neue Tests über Nacht 100 Mal gleichzeitig aus, bevor sie in die CI-Builds aufgenommen werden.
- Lösche fehlerhafte Tests, wenn sie nicht innerhalb der TTL behoben werden; toter Code bringt keinen Nutzen.
Flaky Tests: Grundursachen, echte Auswirkungen und effektive Lösungen
Unzuverlässige Tests sind für moderne Software-Teams fast schon ein allgegenwärtiger Schmerzpunkt. In einer lebhaften Folge von Software Testing Unleashed auf der HUSTEF-Konferenz in Budapest hat Simon Stewart - bekannt als Leiter des Selenium-Projekts - zusammen mit Richie einen ehrlichen Blick darauf geworfen, was schlappe Tests eigentlich sind, warum sie viel wichtiger sind, als wir uns oft eingestehen, und wie Teams sie angehen können, um die Softwarequalität zu verbessern.
Was ist ein "unzuverlässiger Test"?
Viele Teams behandeln fehlerhafte Tests nur als Hintergrundgeräusch: lästig, unberechenbar und am besten zu ignorieren. Simon Stewart sorgte für die nötige Klarheit: Er definierte unzuverlässige Tests nicht als lästiges Übel, sondern als Fehlerwirkung, die sich nicht wiederholen lässt. Mit anderen Worten: Ein fehlerhafter Test besteht manchmal, manchmal schlägt er fehl, auch wenn sich am Code oder der Umgebung nichts geändert hat. Dies untergräbt die entscheidende Eigenschaft der Wiederholbarkeit, ein Eckpfeiler wertvoller automatisierter Tests.
Ein wirklich wertvoller Test ist selbstüberprüfend, schnell, isoliert und - was am wichtigsten ist - wiederholbar. Fehlt einer dieser Eckpfeiler, bricht die Rückkopplungsschleife für Entwickler/innen und das Vertrauen in das System schnell zusammen.
Warum unzuverlässige Tests das Vertrauen zerstören
Das Problem mit unzuverlässigen Tests geht tiefer, als nur Ingenieure zu irritieren oder das Review von Pull Requests zu verlangsamen. Simon Stewart erklärt: "Alles, was kein konsistentes Signal liefert, sei es ein bestandenes oder ein fehlgeschlagenes, zerstört das Vertrauen". Wenn Entwickler/innen den Ergebnissen ihrer CI-Pipeline nicht mehr vertrauen, verlieren sie das Vertrauen, dass automatisierte Prüfungen einen sinnvollen Schutz bieten. Die Leute hören auf, den CI-Status zu überprüfen, akzeptieren grüne Builds widerwillig und verschwenden Zeit damit, Builds erneut zu starten, bis sie "Glück haben" Diese Szenarien verlängern die Feedbackschleifen und untergraben die gesamte Automatisierungsinvestition.
Häufige Ursachen für Flakiness
Während die Symptome von Flakiness offensichtlich sind, sind die Grundursachen sehr vielfältig. Laut Simon Stewart sind die beiden häufigsten Ursachen:
Gleichzeitiger Zugriff auf gemeinsam genutzte Daten: Wenn Tests oder Systeme auf gemeinsam genutzte (oft veränderbare) Daten zugreifen - z. B. statische Variablen in Java oder gemeinsam genutzte Datenbanktabellen - beeinflusst die Reihenfolge der Ausführung das Ergebnis.
Wettlaufbedingungen und Timing-Probleme: Bestimmte Fehler treten nur gelegentlich auf, oft aufgrund von Timing-Unstimmigkeiten, Netzwerkabhängigkeiten oder inkonsistentem Verhalten von APIs.
Hinzu kommen unzuverlässige Dienste von Drittanbietern, Netzwerkfehler, Ausfälle von Abhängigkeiten und knifflige Konfigurationen (z. B. Uhrendrift oder Fehlhandlungen beim Runden von Zeitstempeln) 15:16.
Der Umgang mit fehlerhaften Tests: Praktische Schritte
Bekannte fehlerhafte Tests sofort aus der CI entfernen: Die erste Abwehrmaßnahme ist Klarheit: Unzuverlässige Tests müssen unverzüglich aus den Haupt-CI-Läufen entfernt werden, um das Signal zu erhalten. Verwende Anmerkungen oder, noch besser, eine zentrale Datei mit "übersprungenen Tests". In Projekten wie Selenium listet eine einzige Textdatei alle fehlerhaften Tests auf und vereinfacht so sowohl die Nachverfolgung als auch die eventuelle Sanierung.
Übertrage die Verantwortung: Unerledigte Arbeit wird selten erledigt. Jeder übersprungene oder ignorierte Test sollte einer echten Person gehören, nicht einem Team oder "der Allgemeinheit", sonst besteht das Risiko, dass er auf unbestimmte Zeit liegen bleibt.
Untersuchen oder löschen: Wenn ein fehlerhafter Test nicht mehr funktioniert, solltest du ihn wiederholt durchführen, um das Problem zu identifizieren, und kleine, gezielte Tests schreiben, um die zugrunde liegenden Fehler zu validieren. Wenn ein Test nicht behoben werden kann oder an Relevanz verliert, solltest du ihn löschen - die Quellenkontrolle ermöglicht eine Wiederherstellung, wenn es wirklich nötig ist.
Nutze KI mit Bedacht: KI-Tools können das Debugging unterstützen, indem sie komplizierten Code reviewen, erfordern aber immer menschliche Aufsicht. Vertraue, aber überprüfe - manchmal hilft eine zweite KI-Meinung bei der Validierung von Vorschlägen.
Fehlerhafte Tests von vornherein verhindern
Simon Stewart betonte die Vorbeugung: Lass niemals einen fehlerhaften Test in den Build einfließen. Gatekeeping durch wiederholte Testläufe vor der Zusammenführung (Meta führt einige Tests 100 Mal durch, bevor sie in die KI übernommen werden) ist äußerst effektiv. Auch kleinere Organisationen können ähnliche Ansätze verfolgen, indem sie neue oder geänderte Tests mehrfach ausführen, bevor sie sie akzeptieren.
Wann man sie gehen lassen sollte
Unkorrigierte Tests, die sich hinziehen, nützen niemandem. Viele Teams wenden eine Time-to-Live (TTL) an: Wenn ein fehlerhafter Test nicht innerhalb eines bestimmten Zeitraums wieder stabil ist, wird er gelöscht. Auch wenn sich die Überdeckung an anderer Stelle - insbesondere in niedrigeren, stabileren Schichten - wiederholt, solltest du den Test aus dem Programm nehmen.
Unzuverlässige Tests decken echte Systemschwächen auf, mindern das Vertrauen und führen zu verschwendeten Entwicklungsstunden, wenn sie nicht systematisch angegangen werden. Setze auf Feedback-Stabilität, Transparenz über ignorierte Tests, individuelle Verantwortung und Gatekeeping-Strategien, um dein CI-Signal - und das Vertrauen deiner Entwickler - zurückzugewinnen.