Flaky Tests in Cypress sind Tests, die bei gleichem Code mal bestehen und mal scheitern. Cypress Cloud definiert einen Test als flaky, wenn er erst fehlschlägt und dann im Retry ohne Codeänderung besteht.
Der Fehler sitzt selten im Test Runner. Meist liegt er in Timing, Testdaten, Netzwerk oder in Abhängigkeiten zwischen Tests. Der Test zeigt also auf ein echtes Problem, nur eben nicht jedes Mal.
Flaky Tests kosten Zeit, und sie schwächen das Vertrauen in die ganze Suite. Wenn ein roter Run oft nur Zufall ist, klickt das Team irgendwann auf Neustart und schaut nicht mehr hin. Dann rutscht der echte Bug durch.
Ein flakiger Test ist für uns ein Hinweis auf ein echtes Problem, und dem gehen wir nach. Ein Neustart des Runs reicht uns nicht. Die Triage gehört zu unserem Alltag: Cypress mit Cypress Cloud läuft bei uns täglich in Production, dazu PHPUnit, PHPStan und Psalm in GitHub Actions und GitLab CI. Wird ein Run rot, schauen wir zuerst auf Timing, Daten und Reihenfolge. Roland Golla arbeitet seit über 20 Jahren an Testing und Refactoring und hat viele dieser Muster oft gesehen.
Mit deinem Team suchen wir die Ursachen in der bestehenden Suite, legen Regeln für Retries und Quarantäne fest und bauen stabile Tests auf. Das geht im Cypress Workshop mit Roland Golla oder in der Cypress Remote Schulung für Teams. Wie KI Agenten flakige Tests aus Cypress Cloud abfragen, zeigt Cypress Cloud MCP. Stabile Tests sind die Basis für Quality Gates für KI Code in einer sauberen CI CD Pipeline mit Docker und Staging. Für reproduzierbare Daten sorgen Faker Testdaten für die lokale Entwicklung.
Ein Tag inhouse mit Roland Golla, offizieller Cypress Ambassador und seit über 20 Jahren in Testing und Refactoring zu Hause. Auf unserem YouTube Kanal zeigt er in über 70 Live Coding Tutorials, wie Cypress in echten Projekten läuft. Dazu kommt unser Open Source Plugin NCA TESTIFY: Basistests für jede Website, mit einer Zeile im CI/CD Setup. Im Workshop lernt euer Team Setup, stabile Selektoren, Custom Commands und Tests in der Pipeline.
Ein flakiger Test hat fast immer eine konkrete Ursache. Sie zeigt sich nur nicht bei jedem Lauf. Diese sechs Kandidaten prüfen wir zuerst:
Dazu kommt die Umgebung. Im CI hat der Runner oft weniger CPU als dein Laptop. Ein Test, der lokal knapp gelingt, kippt im CI. Darum ist lokal grün noch kein Beweis.
Der Klassiker unter den Flaky Ursachen ist die feste Wartezeit. Die Cypress Doku nennt das Warten auf beliebige Zeiträume mit cy.wait(Number) ausdrücklich ein Anti Pattern. Ist die Anwendung schneller, verschwendest du Zeit. Ist sie langsamer, scheitert der Test.
// Schlecht: feste Wartezeit
cy.get('[data-cy=save]').click()
cy.wait(3000)
cy.get('[data-cy=toast]').contains('Gespeichert')
Besser ist es, auf einen Zustand zu warten. Cypress wiederholt Queries mit ihren Assertions automatisch, bis sie bestehen oder das Timeout erreicht ist. Standard sind 4 Sekunden über defaultCommandTimeout.
// Gut: auf den sichtbaren Zustand warten
cy.get('[data-cy=save]').click()
cy.get('[data-cy=toast]').should('be.visible').and('contain', 'Gespeichert')
Hängt der Zustand an einem Request, wartest du direkt auf den Request. Mit cy.intercept und einem Alias weiß Cypress genau, worauf es warten soll. Bonus: Du kannst gleich den Statuscode prüfen.
// Gut: auf den Request warten statt auf die Uhr
cy.intercept('POST', '/api/orders').as('saveOrder')
cy.get('[data-cy=save]').click()
cy.wait('@saveOrder').its('response.statusCode').should('eq', 201)
cy.get('[data-cy=toast]').should('contain', 'Gespeichert')
Ein zweiter Fallstrick: Assertions direkt hinter Aktionen. Aktionen wie click() laufen nur einmal und werden nicht wiederholt. Die Doku empfiehlt, Ketten nach einer Aktion zu beenden und das Element neu abzufragen. Mehr Praxis zu Wartestrategien findest du im NCA Blog unter Cypress Wait Best Practices.
Feste Wartezeiten musst du nicht von Hand suchen. Das ESLint Plugin für Cypress meldet sie automatisch über die Regel no-unnecessary-waiting, schon im Editor und im CI.
Zwei Begriffe klingen gleich und werden oft verwechselt:
Ein typisches Setup: Im CI bekommt jeder Test bis zu zwei weitere Versuche, lokal keinen. So siehst du Flakiness beim Entwickeln sofort.
import { defineConfig } from 'cypress'
export default defineConfig({
retries: {
runMode: 2,
openMode: 0,
},
})
Retries lassen sich auch pro Test oder pro describe Block setzen. Bei einem Retry laufen beforeEach und afterEach erneut. Fehler in before und after Hooks lösen dagegen keinen Retry aus.
it('legt eine Bestellung an', { retries: { runMode: 2, openMode: 1 } }, () => {
// Testcode
})
Cypress bietet außerdem experimentelle Retry Strategien. Mit detect-flake-and-pass-on-threshold legst du fest, wie viele Versuche bestehen müssen. Mit detect-flake-but-always-fail bleibt ein flakiger Test rot, wird aber als flaky erkannt. Wichtig: Ein Retry zeigt dir, dass ein Test wackelt. Die Ursache musst du danach selbst finden und beheben.
retries: {
experimentalStrategy: 'detect-flake-but-always-fail',
experimentalOptions: {
maxRetries: 2,
stopIfAnyPassed: true,
},
openMode: true,
runMode: true,
}
Ein einzelner flakiger Lauf sagt wenig. Aussagekräftig wird es erst über viele Runs hinweg. Dafür gibt es das Flaky Test Management in Cypress Cloud. Die Grundlage sind Test Retries. Ohne aktivierte Retries erkennt Cypress Cloud laut Doku keine Flaky Tests.
Was Cypress Cloud laut Doku bietet:
Zur Verfügbarkeit: Flaky Test Management setzt laut Cypress Doku mindestens den Team Plan voraus. Organisationsweites Reporting und die Data Extract API sind dem Enterprise Plan vorbehalten.
Für die Ursachensuche kombinierst du Flake Detection mit Test Replay. Du vergleichst den roten mit dem grünen Versuch und siehst, was beim ersten Mal anders war. Und mit Cypress Cloud MCP holt ein KI Agent die flakigen Tests eines Runs direkt in den Editor. Welche Daten dabei in die Cloud dürfen, klärt Testdaten in Cypress.
KI Agenten schreiben Cypress Tests in Sekunden. Sie schreiben dabei auch die alten Fehler in Sekunden. Feste Wartezeiten, Selektoren auf CSS Klassen, Tests, die aufeinander aufbauen. Ein Agent hat aus seinen Trainingsdaten gelernt, und dort steckt viel cy.wait(2000).
Gefährlich wird es beim Reparieren. Ein Agent, der einen roten Test grün machen soll, greift gern zur bequemen Lösung: längeres Timeout, mehr Retries, Assertion entfernen. Der Test ist dann grün, das Problem bleibt.
Welche Regeln für Agenten, Review und Freigabe bei uns gelten, steht auf der Seite Cypress mit KI Agenten. Bevor ein neuer Test gemergt wird, lassen wir ihn mit den Burn Tests aus Cypress Grep mehrfach hintereinander laufen. Wackelt er dabei, fällt das vor dem Merge auf.
Ein Einstieg in KI generierte Tests ist cy.prompt. Damit bekommst du schnell erste lauffähige Tests in natürlicher Sprache. Stabile Suiten brauchen trotzdem Testing Wissen, das über generierte Tests hinausgeht. Wie ein Team Standards für KI Tests festlegt, beschreibt unser Blogbeitrag Testing Meta für Cypress.
Nicht jeder flakige Test lässt sich sofort reparieren. Dann braucht das Team eine Regel, sonst entscheidet jeder anders. Wir arbeiten mit drei Fragen:
Quarantäne heißt: Der Test läuft weiter, aber in einer eigenen Suite. Er blockiert den Merge nicht mehr, wird aber beobachtet. Mit Tags und einem Filter wie @cypress/grep trennst du die Suiten sauber.
describe('Checkout', { tags: '@quarantine' }, () => {
// TODO: Ticket mit Verantwortlichem und Frist verlinken
it('zeigt die Versandoptionen', () => {
// Testcode
})
})
Die wichtigste Regel: Quarantäne ist ein Wartebereich. Hat die Quarantäne kein Limit, wächst sie still weiter. Begrenze die Zahl der Tests darin oder die Zeit, die ein Test dort bleiben darf. Und lösch einen Test lieber, als ihn für immer zu ignorieren.
Place any non-deterministic test in a quarantined area. (But fix quarantined tests quickly.)
Cypress Cloud MCP verbindet KI Agenten direkt mit Testergebnissen, Flaky Tests und Test Replay. Setup für OpenCode und Claude Code, eingeordnet von NCA.
Mehr erfahren
Agentische Akzeptanztests erklärt: wie Akzeptanzkriterien zum Maßstab für KI Agenten werden, welche Risiken drohen und wie Teams 2026 absichern
Mehr erfahrenViele Flaky Tests entstehen, weil unklar ist, was eigentlich geprüft werden soll. Darum starten wir mit Example Mapping und halten Regeln und Beispiele als lebende Spezifikation fest. Ein Test mit klarem Ziel hat eine klare Assertion, und eine klare Assertion wackelt selten.
Flakiness gibt es auch jenseits von Cypress, das zeigt unser Blogbeitrag zu PHPUnit 13.3 und Flaky Tests. Für Teams mit KI Agenten beschreiben die NCA Agentic AI Coding Guardrails den Rahmen, Vibe Coding Risiken zeigt, wo es ohne Tests kippt. In der Vibe Coding Beratung und der KI Weiterbildung für Entwicklerteams bauen wir Flaky Tests mit dir systematisch ab: Ursachen finden, Regeln festlegen, Quarantäne einführen.
Barrierefreiheit prüfen wir in denselben Suiten mit axe und Cypress. Passend dazu im NCA Cypress Glossar: Self Healing Tests und was Cypress bei Selektoren wirklich kann.
Optimieren Sie Ihre Webseite mit Astro JS und nutzen Sie die Vorteile einer schnellen, sicheren und barrierefreien Webseite. Erfüllen Sie die gesetzlichen Anforderungen und verbessern Sie die Benutzererfahrung Ihrer Webseite. Mit Astro JS können Sie die Ladezeit reduzieren, die Sicherheit maximieren und die SEO-Optimierung verbessern. Kontaktieren Sie uns, um mehr zu erfahren und um Ihre Webseite auf ein neues Level zu heben.
Die wichtigsten Fragen zu Ursachen, Retries, Flake Detection und Quarantäne bei Flaky Tests.
Flaky Tests sind Tests, die bei gleichem Code mal bestehen und mal scheitern. Cypress Cloud nennt einen Test flaky, wenn er erst fehlschlägt und im Retry ohne Codeänderung besteht. Die Ursache liegt meist in Timing, Testdaten, Netzwerk oder Abhängigkeiten zwischen Tests. Der Test zeigt auf ein echtes Problem, nur nicht bei jedem Lauf.
Die Klassiker sind feste Wartezeiten, Race Conditions zwischen Klick und Request, geteilte oder zufällige Testdaten und Tests, die auf den Zustand anderer Tests bauen. Dazu kommen langsame externe Dienste, Animationen und fragile Selektoren auf CSS Klassen. Im CI verstärkt weniger Rechenleistung diese Effekte, deshalb ist lokal grün noch kein Beweis.
Über das Flaky Test Management. Voraussetzung sind aktivierte Test Retries, ohne sie erkennt Cypress Cloud laut Doku keine Flakiness. Dann bekommen Tests ein Flaky Badge, Runs lassen sich filtern, und jeder Test erhält eine Einstufung nach Flake Rate. Benachrichtigungen gehen unter anderem an GitHub, GitLab, Slack und Microsoft Teams.
Laut Cypress Doku braucht Flaky Test Management mindestens den Team Plan. Organisationsweites Reporting und die Data Extract API sind dem Enterprise Plan vorbehalten. Test Replay dagegen steht laut Doku in allen Plänen zur Verfügung, mit Nutzungsgrenzen. Prüf die aktuellen Bedingungen direkt bei Cypress, weil sich Pläne ändern können.
Ja, vor allem bei der Analyse. Über Cypress Cloud MCP holt ein Agent flakige Tests samt Replay Link in den Editor und schlägt einen Fix vor, den ein Mensch prüft. Beim Schreiben neuer Tests erzeugen Agenten aber oft selbst Flakiness, etwa durch feste Wartezeiten. Burn Tests vor dem Merge fangen das ab.
Retry-ability ist eingebaut und wirkt innerhalb eines Tests. Cypress wiederholt Queries wie cy.get samt Assertion, bis sie bestehen oder das Timeout abläuft, standardmäßig 4 Sekunden. Test Retries wiederholen dagegen den ganzen Test nach einem Fehlschlag. Sie sind standardmäßig aus und werden über die Option retries in der Konfiguration eingeschaltet.
Weil eine feste Zeit nie passt. Ist die Anwendung schneller, verschwendet der Test Zeit. Ist sie langsamer, scheitert er. Die Cypress Doku nennt cy.wait mit einer Zahl ein Anti Pattern. Besser sind Assertions auf den sichtbaren Zustand oder cy.wait auf einen Alias, den du vorher mit cy.intercept angelegt hast.
Ein guter Start sind im CI ein bis zwei weitere Versuche, lokal keine. So erkennt Cypress Cloud Flakiness, und beim Entwickeln fällt sie sofort auf. Mehr Retries verstecken Probleme nur länger und verlängern rote Runs. Ein Test, der regelmäßig erst im zweiten Versuch besteht, gehört auf die Liste der Tests, die repariert werden.
Nur als letzte Möglichkeit. Zuerst suchst du die Ursache, denn oft zeigt der Test auf einen echten Fehler in Timing oder Daten. Lässt sich das nicht sofort lösen, wandert der Test mit Ticket und Frist in Quarantäne. Bleibt er dort zu lange ohne Fortschritt, ist Löschen ehrlicher als dauerhaftes Ignorieren.
Der Test läuft weiter, aber in einer eigenen Suite, die den Merge nicht blockiert. So bleibt die Hauptsuite verlässlich, und der Test wird trotzdem beobachtet. Wichtig sind ein Ticket, ein Verantwortlicher und eine Frist. Begrenze die Zahl der Tests in Quarantäne, sonst wird sie zur stillen Ablage für Probleme.
Jeder Test sollte seine Daten selbst anlegen und nicht von anderen Tests abhängen. Die Cypress Doku sagt klar, dass Tests unabhängig voneinander laufen und bestehen müssen. Mit erzeugten Fake Daten, etwa über Faker, und einer frischen Datenbasis pro Lauf verschwinden viele Fehler, die nur in bestimmter Reihenfolge auftreten.
Eigene data Attribute wie data-cy. Die Cypress Doku empfiehlt sie, weil sie von CSS und JavaScript Änderungen unabhängig sind. Selektoren auf Klassen oder sichtbare Texte brechen bei jedem Redesign. Ein data-cy Attribut zeigt zudem allen im Team, dass ein Test an diesem Element hängt und es nicht nebenbei geändert werden sollte.
