NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Wackelnde Ampel wird mit Schraubenschlüssel stabilisiert, Flaky Tests

Was sind Flaky Tests in Cypress?

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.

Das Tückische daran: 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 mehr als Zeit. Sie kosten Vertrauen. Wenn ein roter Run oft nur Zufall ist, klickt das Team irgendwann auf Neustart und schaut nicht mehr hin. Genau dann rutscht der echte Bug durch.

Inhalt

Flaky Tests mit NCA: Schnelle Hilfe vom Experten

Bei uns läuft Cypress mit Cypress Cloud täglich in Production, dazu PHPUnit, PHPStan und Psalm in GitHub Actions und GitLab CI. Roland Golla ist offizieller Cypress Ambassador und arbeitet seit über 20 Jahren an Testing und Refactoring. Automatisiert testen wir bei NCA seit 2013, auch Tests zum TYPO3 Core hat Roland beigetragen. Ein flakiger Test ist für uns ein Hinweis, dem wir nachgehen.

Im Cypress Workshop mit Roland bauen wir stabile Tests gemeinsam auf, für Teams gibt es die Cypress Remote Schulung. 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.

NCA Cypress Workshop mit Cypress Ambassador Roland Golla

E2E Tests, die euer Team selbst schreibt

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.

  1. 1
    Kostenloses Vorgespräch
    Projekt, Stack und Teststand klären
  2. 2
    Workshoptag bei euch
    Setup, Patterns und erste Tests im Team
  3. 3
    Praxistag optional
    Tests im eigenen Projekt und in CI
Roland Golla
Roland Golla
Fullstack Developer
Zum Cypress Workshop arrow_forward

Die häufigsten Ursachen für Flaky Tests

Ein flakiger Test hat fast immer eine konkrete Ursache. Sie zeigt sich nur nicht bei jedem Lauf. Diese sechs Kandidaten prüfen wir zuerst:

  • Timing: Der Test ist schneller als die Anwendung. Ein Element ist noch nicht da, ein Request noch nicht fertig.
  • Race Conditions: Zwei Dinge passieren gleichzeitig, und die Reihenfolge ist mal so und mal so.
  • Testdaten: Daten sind zufällig, veraltet oder werden von einem anderen Test verändert.
  • Abhängigkeiten zwischen Tests: Ein Test braucht den Zustand, den ein anderer hinterlassen hat.
  • Netzwerk: Externe Dienste antworten langsam oder gar nicht.
  • Animationen: Ein Element bewegt sich noch, wird überdeckt oder ist noch nicht klickbar.

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.

Ursache, Symptom und Fix im Überblick

So erkennst du die typischen Ursachen am Symptom und behebst sie dauerhaft.
Ursache Symptom Fix
Timing Element nicht gefunden, Timeout nach einigen Sekunden Auf Zustand warten: Assertion mit should statt cy.wait mit fester Zeit
Race Condition Test klickt, bevor Daten geladen sind, Ergebnis wechselt Request mit cy.intercept als Alias abfangen und mit cy.wait auf den Alias warten
Testdaten Fehler nur bei bestimmten Datensätzen oder nach anderen Tests Daten pro Test frisch anlegen, Fake Daten statt geteilter Datenbank
Abhängigkeit zwischen Tests Test besteht nur in einer bestimmten Reihenfolge Jeden Test isoliert aufsetzen, Zustand per API oder cy.session herstellen
Netzwerk Sporadische Fehler bei externen Diensten Externe Requests mit cy.intercept und Fixtures stubben
Animation Element ist verdeckt oder bewegt sich beim Klick Auf sichtbaren Endzustand prüfen, Animationen in der Testumgebung abschalten
Fragile Selektoren Test bricht nach CSS oder Text Änderungen Eigene data-cy Attribute als Selektoren nutzen

Schlecht und gut: cy.wait gegen Assertions und Aliase

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.

Code: 
          
// 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.

Code: 
          
// 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.

Code: 
          
// 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.

Retry-ability und Test Retries: zwei verschiedene Dinge

Zwei Begriffe klingen gleich und werden oft verwechselt:

  • Retry-ability ist eingebaut. Cypress wiederholt Queries wie cy.get oder cy.find samt Assertion, bis sie bestehen oder das Timeout abläuft. Das passiert innerhalb eines Tests, bei jedem Lauf.
  • Test Retries wiederholen den ganzen Test, wenn er fehlschlägt. Das musst du einschalten, Standard ist 0 für runMode und openMode.

Ein typisches Setup: Im CI bekommt jeder Test bis zu zwei weitere Versuche, lokal keinen. So siehst du Flakiness beim Entwickeln sofort.

Code: 
          
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.

Code: 
          
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: Retries machen Flakiness sichtbar. Sie beheben sie nicht.

Code: 
          
retries: {
  experimentalStrategy: 'detect-flake-but-always-fail',
  experimentalOptions: {
    maxRetries: 2,
    stopIfAnyPassed: true,
  },
  openMode: true,
  runMode: true,
}

Flake Detection in Cypress Cloud

Ein einzelner flakiger Lauf sagt wenig. Spannend wird es über viele Runs hinweg. Genau 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:

  • Flaky Badge an Tests, die nach einem Retry bestanden haben
  • Markierung und Filter für Runs mit flakigen Tests
  • Einstufung nach Flake Rate: niedrig bis 10 Prozent, mittel bis 50 Prozent, hoch darüber
  • Benachrichtigungen über GitHub, GitLab, Bitbucket, Slack und Microsoft Teams

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. Cypress Cloud ist ein US Anbieter. Nutz in Testumgebungen deshalb nur Fake Daten.

Flaky Tests bei KI generierten Tests

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.

Darum gelten bei uns klare Regeln:

  • Der Agent schreibt Tests, ein Mensch reviewt und gibt frei.
  • Bestehende Testdateien sind geschützt. Änderungen daran brauchen eine Begründung.
  • Regeln wie keine festen Wartezeiten und nur data-cy Selektoren stehen in der AGENTS.md mit den Coding Regeln.
  • Agenten laufen gegen lokale Umgebungen mit Fake Daten, nie gegen Production.
  • Jeder Test läuft durch die Quality Gates in CI, bevor er zählt.

Ein Einstieg in KI generierte Tests ist cy.prompt. Es ist ein guter Weg, mit dem Testen anzufangen und nach vorne zu gehen. 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.

Fixen oder quarantänieren: eine klare Strategie

Nicht jeder flakige Test lässt sich sofort reparieren. Dann braucht das Team eine Regel, sonst entscheidet jeder anders. Wir arbeiten mit drei Fragen:

  • Ist die Ursache klar? Dann wird sofort gefixt, im selben Sprint.
  • Ist der Test kritisch? Login, Checkout und Kernabläufe bleiben in der Hauptsuite und werden bevorzugt repariert.
  • Blockiert der Test andere? Dann wandert er in Quarantäne, mit Ticket, Verantwortlichem und Frist.

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.

Code: 
          
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.)

Martin Fowler, Chief Scientist, Thoughtworks – Eradicating Non-Determinism in Tests, martinfowler.com

Aus der NCA Praxis: Stabilität beginnt vor dem Test

Viele 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. Wie PHPUnit flakige Tests erkennt, 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, und Vibe Coding Risiken zeigt, wo es ohne Tests kippt.

Wir helfen Teams, Flaky Tests systematisch abzubauen: Ursachen finden, Regeln festlegen, Quarantäne einführen. Dazu gibt es unser Vibe Coding Consulting und die KI Weiterbildung für Entwicklerteams. 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.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Frontend 2025: Optimieren Sie Ihre Webseite mit Astro JS und nutzen Sie die Vorteile der Barrierefreiheit

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.

Astro JS Frontend E-Mail Kontakt

Häufige Fragen zu Flaky Tests in Cypress

Die wichtigsten Fragen zu Ursachen, Retries, Flake Detection und Quarantäne bei Flaky Tests.

Was sind Flaky Tests in Cypress 2026?

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.

Was sind 2026 die häufigsten Ursachen für Flaky Tests?

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.

Wie erkenne ich Flaky Tests in Cypress Cloud 2026?

Ü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.

Welcher Cypress Cloud Plan bietet 2026 Flake Detection?

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.

Helfen KI Agenten 2026 gegen Flaky Tests?

Ja, bei der Analyse. Über Cypress Cloud MCP holt ein Agent flakige und fehlgeschlagene Tests samt Replay Link in den Editor und schlägt einen Fix vor. Ein Mensch prüft und gibt frei. Beim Schreiben neuer Tests erzeugen Agenten dagegen oft selbst Flakiness, etwa durch feste Wartezeiten. Klare Regeln und Review sind deshalb Pflicht.

Was ist der Unterschied zwischen Retry-ability und Test Retries?

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.

Warum ist cy.wait mit fester Zeit ein Problem?

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.

Wie viele Test Retries sind sinnvoll?

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.

Sollte ich Flaky Tests löschen?

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.

Was bedeutet Quarantäne für Flaky Tests?

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.

Wie helfen Testdaten gegen Flakiness?

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.

Welche Selektoren machen Cypress Tests stabil?

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.