NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüner Prüfbogen testet Cypress Test Roboter mit ESLint

Was ist das ESLint Plugin für Cypress?

Das ESLint Plugin für Cypress heißt auf npm eslint-plugin-cypress und ist das offizielle Lint Plugin des Cypress Teams. Es kennt die Globals cy und Cypress und meldet typische Anti Patterns wie feste Wartezeiten oder async Tests, bevor ein Test überhaupt läuft.

Die Regeln setzen einen Teil der offiziellen Cypress Best Practices direkt im Editor um. Du siehst den Fehler in VS Code, PhpStorm oder Vim schon beim Tippen. Das Plugin steht unter MIT Lizenz und wird vom Cypress Team auf GitHub gepflegt.

Die Meldungen zielen auf genau die Muster, aus denen später Flaky Tests werden: Tests, die mal grün und mal rot sind, obwohl sich am Code nichts geändert hat. Das macht das Plugin besonders wertvoll, wenn KI Agenten Cypress Tests schreiben.

Inhalt

ESLint Plugin Cypress mit NCA, schnelle Hilfe vom Experten

Bei uns kommt eslint-plugin-cypress in jedes neue Cypress Projekt, noch vor dem ersten Test. Der Grund ist simpel. Roland Golla zeigt als Cypress Ambassador in über 70 Live Coding Tutorials auf dem NCA YouTube Kanal, wie Tests entstehen, die auch nach Monaten noch grün sind. Viele Fehler, die wir dort Schritt für Schritt korrigieren, meldet das Plugin heute automatisch: ein cy.wait mit fester Zahl, ein gespeicherter Rückgabewert, ein Klick mit force. Seit KI Agenten mitschreiben, ist Linting für uns die eine Regel, über die wir nicht verhandeln.

Im Cypress Workshop mit Roland Golla schalten wir die Regeln gemeinsam mit deinem Team ein und gehen die ersten Meldungen Spec für Spec durch. Ganze Teams holen wir über die Cypress Remote Schulung ab. In der Pipeline wird der Linter zum ersten Quality Gate für KI Code, eingerichtet über ein sauberes CI/CD Pipeline Setup und eingebettet in die NCA Agentic AI Coding Guardrails. Wer nicht bei null starten will, bindet zusätzlich das NCA TESTIFY Cypress Plugin mit einer Zeile ins CI/CD Setup ein und hat sofort Basistests für Links, Bilder und Barrierefreiheit.

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

Installation mit Flat Config in zwei Minuten

Das Plugin braucht ESLint 9 oder 10. Ältere Versionen unterstützt es nicht mehr. Du installierst ESLint und das Plugin als Dev Abhängigkeit.

Code: 
          
npm install eslint eslint-plugin-cypress --save-dev

Die alte .eslintrc Datei ist Geschichte. ESLint 10 kennt nur noch die Flat Config, und das Plugin unterstützt das alte Format ebenfalls nicht mehr. Du legst also eine eslint.config.mjs im Projektroot an und aktivierst die empfohlenen Regeln nur für den Cypress Ordner.

Code: 
          
// eslint.config.mjs
import { defineConfig } from 'eslint/config'
import pluginCypress from 'eslint-plugin-cypress'

export default defineConfig([
  {
    files: ['cypress/**/*.{js,ts}'],
    extends: [pluginCypress.configs.recommended],
  },
])

Zwei Konfigurationen bringt das Plugin mit:

  • configs.globals definiert cy, Cypress, expect, assert und chai sowie die Browser und Mocha Globals. Regeln sind dort keine aktiv.
  • configs.recommended enthält die Globals und schaltet zusätzlich die empfohlenen Regeln ein.

Wer noch eslint-plugin-cypress/flat importiert, muss umstellen. Der Suffix /flat ist entfernt, der Import lautet nur noch eslint-plugin-cypress.

Die vier empfohlenen Regeln und was sie verhindern

Die Recommended Konfiguration ist bewusst klein. Vier Regeln sind aktiv, und jede davon verhindert einen Fehler, den wir in Code Reviews immer wieder sehen.

  • no-unnecessary-waiting verbietet feste Wartezeiten wie cy.wait(3000). Sie machen Tests langsam und trotzdem flaky.
  • no-assigning-return-values verbietet, das Ergebnis eines cy Aufrufs in eine Variable zu schreiben. Cypress Befehle laufen asynchron in einer Queue.
  • no-async-tests verbietet async und await in Testfällen. Cypress Ketten sind keine Promises.
  • unsafe-to-chain-command verbietet Ketten nach Aktionen wie click, bei denen sich die Seite schon geändert haben kann.

So sieht der Klassiker aus, den das Plugin sofort meldet:

Code: 
          
// schlecht: feste Wartezeit
cy.get('[data-cy=save]').click()
cy.wait(3000)
cy.get('[data-cy=toast]').should('be.visible')

// gut: auf den Request warten
cy.intercept('POST', '/api/articles').as('save')
cy.get('[data-cy=save]').click()
cy.wait('@save')
cy.get('[data-cy=toast]').should('be.visible')

Ein cy.wait mit Alias ist erlaubt. Die Regel greift nur bei Zahlen, also bei Wartezeiten ohne Bezug zu dem, was in der Anwendung passiert.

Weitere Regeln, die wir zusätzlich einschalten

Neben den empfohlenen Regeln bringt das Plugin weitere mit, die du einzeln aktivierst. Wir schalten die meisten davon ein, vor allem in Teams, in denen KI Agenten mitschreiben.

Code: 
          
// eslint.config.mjs
import { defineConfig } from 'eslint/config'
import pluginCypress from 'eslint-plugin-cypress'

export default defineConfig([
  {
    files: ['cypress/**/*.{js,ts}'],
    extends: [pluginCypress.configs.recommended],
    rules: {
      'cypress/require-data-selectors': 'error',
      'cypress/no-force': 'error',
      'cypress/no-pause': 'error',
      'cypress/no-debug': 'error',
      'cypress/assertion-before-screenshot': 'warn',
      'cypress/no-and': 'warn',
    },
  },
])

Was die zusätzlichen Regeln bringen:

  • require-data-selectors erzwingt data Attribute als Selektoren. Das passt zu unserer data-cy Konvention aus den Cypress Custom Commands.
  • no-force verbietet force: true. Wer erzwingt, versteckt meist einen echten Bedienfehler.
  • no-pause und no-debug verhindern, dass Debug Befehle in den Main Branch rutschen.
  • assertion-before-screenshot sorgt dafür, dass ein Screenshot erst nach einer Assertion entsteht, wenn die Seite wirklich bereit ist.
  • no-and verlangt should statt and am Anfang einer Assertion Kette und ist automatisch mit --fix korrigierbar.

Regeln von eslint-plugin-cypress im Überblick

Regel Was sie verhindert Status
no-unnecessary-waiting Feste Wartezeiten mit cy.wait und einer Zahl Recommended
no-assigning-return-values Rückgabewerte von cy in Variablen Recommended
no-async-tests async und await in Testfällen Recommended
unsafe-to-chain-command Ketten nach Aktionen wie click Recommended
require-data-selectors Selektoren über CSS Klassen oder Texte Optional
no-force force: true bei Aktionen Optional
no-pause, no-debug Debug Befehle im Repository Optional
assertion-before-screenshot Screenshots vor dem fertigen Zustand Optional
no-chained-get Ketten aus mehreren cy.get Optional
no-and and am Anfang einer Assertion Kette Optional, mit --fix

Linting in der Pipeline als Quality Gate

Wir lassen ESLint als eigenen Job vor jedem Cypress Lauf laufen. So bricht die Pipeline beim ersten Lint Fehler ab, und Cypress Cloud startet gar nicht erst.

Code: 
          
# .gitlab-ci.yml
lint:cypress:
  stage: test
  image: node:22
  script:
    - npm ci
    - npx eslint cypress --max-warnings=0

Mit --max-warnings=0 brechen auch Warnungen den Lauf ab. Das klingt streng, verhindert aber, dass sich Warnungen über Wochen sammeln und niemand sie mehr liest. In GitHub Actions sieht der Schritt genauso aus, nur in der Workflow Syntax.

Die Reihenfolge ist bei uns immer gleich: erst statische Analyse, dann Unit Tests, dann funktionale Tests, dann Cypress E2E. Wie diese Kette in Pipelines mit KI Agenten aussieht, zeigen die Vibe Coding CI/CD Pipelines.

Warum KI Agenten das Plugin dringend brauchen

KI Agenten schreiben Cypress Tests schnell. Sie greifen dabei gern zu den Mustern, die im Training häufig vorkamen: cy.wait mit festen Zahlen, async Tests, Selektoren über CSS Klassen und force: true, wenn ein Klick nicht klappt. Der Test läuft dann vielleicht lokal, wird aber in der Pipeline flaky.

Das ESLint Plugin ist hier die billigste Guardrail, die es gibt. Der Agent führt den Linter aus, liest die Meldung und korrigiert sich im selben Loop. Das schreiben wir als Regel in die AGENTS.md:

Code: 
          
## Cypress Linting

- Nach jeder Änderung an Cypress Dateien: npx eslint cypress --max-warnings=0
- Lint Fehler selbst beheben, Regeln nie per eslint-disable abschalten.
- Kannst du eine Meldung nicht lösen: stoppen und nachfragen.

Wichtig ist der zweite Punkt. Ein Agent, der einen Lint Fehler nicht lösen kann, schreibt sonst gern einen eslint-disable Kommentar darüber. Dagegen helfen die Regel in der AGENTS.md, ein Review vor dem Merge und die offiziellen Cypress AI Skills, die Agenten die Cypress Best Practices gleich mitgeben. Wie Agenten danach Testergebnisse lesen, zeigt Cypress Cloud MCP.

Kombination mit Mocha Regeln und TypeScript

Cypress baut auf Mocha und Chai auf. Zwei Ergänzungen empfiehlt die README des Plugins selbst:

  • eslint-plugin-mocha findet vergessene .only und .skip. Ein vergessenes .only lässt sonst nur noch einen Test laufen, und die Pipeline bleibt trotzdem grün.
  • eslint-plugin-chai-friendly verhindert Fehlalarme der Regel no-unused-expressions bei Assertions wie expect(value).to.be.true.
Code: 
          
npm install eslint-plugin-mocha@^11 --save-dev
Code: 
          
// eslint.config.mjs
import { defineConfig } from 'eslint/config'
import pluginMocha from 'eslint-plugin-mocha'
import pluginCypress from 'eslint-plugin-cypress'

export default defineConfig([
  {
    files: ['cypress/**/*.{js,ts}'],
    extends: [
      pluginMocha.configs.recommended,
      pluginCypress.configs.recommended,
    ],
    rules: {
      'mocha/no-exclusive-tests': 'error',
      'mocha/no-pending-tests': 'error',
      'mocha/no-mocha-arrows': 'off',
    },
  },
])

Für TypeScript Projekte kannst du optional Typed Linting mit @typescript-eslint/parser aktivieren. Die Regeln bekommen dann mehr Informationen über dein Projekt. Das kostet Laufzeit, weil der Parser das ganze Projekt liest. Für die meisten Suiten reicht der Standard ohne Typed Linting.

An ESLint plugin for your Cypress tests.

Cypress Team, Maintainer von eslint-plugin-cypress – README auf GitHub

Aus der NCA Praxis, Linting ist die erste Testebene

Wenn wir eine bestehende Cypress Suite übernehmen, schalten wir als Erstes das Plugin mit allen Regeln ein und schauen auf die Zahl der Meldungen. Sie sagt schnell, wo die Suite steht. Viele no-unnecessary-waiting Treffer bedeuten fast immer Flaky Tests. Viele force: true bedeuten, dass Tests an echten Bedienproblemen vorbeiklicken.

Danach räumen wir in kleinen Schritten auf, nie alles auf einmal. Neue Tests müssen sofort sauber sein, alte Meldungen bauen wir Spec für Spec ab. So bleibt die Pipeline grün, und die Suite wird jede Woche stabiler. Das gleiche Prinzip nutzen wir bei Code Qualität mit KI Agenten: erst Quality Gates, dann aufräumen.

Passend dazu im NCA Cypress Glossar: Cypress Grep als nächste Stufe für Smoke Tests und Tests nach Umgebung, das Cypress AI Toolkit für Agenten, die Tests schreiben, Testdaten in Cypress und Cypress Test Replay für Fehler aus der CI. Linting als Guardrail für Agenten richten wir auch in der KI Weiterbildung für Entwicklerteams ein.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Frontend: 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.

E-Mail Kontakt

Häufige Fragen zum ESLint Plugin für Cypress

Die wichtigsten Antworten zu Installation, Flat Config, Regeln, Pipeline und KI Agenten.

Was ist eslint-plugin-cypress 2026?

eslint-plugin-cypress ist das offizielle ESLint Plugin des Cypress Teams. Es definiert die Globals cy und Cypress und bringt Regeln mit, die typische Anti Patterns in Cypress Tests melden, etwa feste Wartezeiten, async Tests oder unsichere Ketten nach Aktionen. Du siehst die Fehler direkt im Editor und in der Pipeline, bevor ein Test läuft.

Welche ESLint Version brauche ich 2026?

Das Plugin setzt ESLint 9 oder 10 voraus. Ältere Versionen werden nicht mehr unterstützt. Ab ESLint 10 gibt es nur noch die Flat Config, und auch das Plugin unterstützt das alte eslintrc Format nicht mehr. Du konfigurierst es also in einer eslint.config.mjs im Projektroot.

Wie richte ich das Plugin 2026 mit Flat Config ein?

Du installierst eslint und eslint-plugin-cypress als Dev Abhängigkeit. In der eslint.config.mjs importierst du das Plugin und nutzt defineConfig mit einem Block für cypress/**/*.{js,ts}. Dort setzt du extends auf pluginCypress.configs.recommended. Einzelne Regeln ergänzt du im rules Objekt mit dem Präfix cypress.

Welche Regeln sind 2026 im Recommended Set?

Vier Regeln sind aktiv: no-unnecessary-waiting gegen feste Wartezeiten, no-assigning-return-values gegen gespeicherte cy Rückgabewerte, no-async-tests gegen async und await in Tests und unsafe-to-chain-command gegen Ketten nach Aktionen wie click. Weitere Regeln wie require-data-selectors oder no-force schaltest du selbst ein.

Hilft das Plugin 2026 bei KI generierten Tests?

Ja, sehr. KI Agenten schreiben oft feste Wartezeiten, CSS Selektoren oder force: true. Der Linter meldet das sofort, und der Agent kann den Fehler im selben Durchlauf beheben. Wichtig ist eine Regel in der AGENTS.md, dass Lint Fehler behoben und nie per eslint-disable abgeschaltet werden. Ein Mensch reviewt trotzdem vor dem Merge.

Was ist der Unterschied zwischen globals und recommended?

configs.globals definiert nur die Globals cy, Cypress, expect, assert und chai sowie Browser und Mocha Globals. Regeln sind dort nicht aktiv. configs.recommended enthält dieselben Globals und schaltet zusätzlich die vier empfohlenen Regeln ein. Für die meisten Projekte ist recommended der richtige Start.

Was passiert mit dem alten Import eslint-plugin-cypress/flat?

Der Import mit dem Suffix /flat wurde mit Version 5 als veraltet markiert und ist inzwischen entfernt. Du importierst das Plugin jetzt nur noch als eslint-plugin-cypress. Die Konfigurationen heißen gleich, du lässt beim Update einfach den Suffix weg und prüfst danach den Lint Lauf.

Darf ich cy.wait überhaupt noch nutzen?

Ja, mit einem Alias. cy.wait mit einem Alias aus cy.intercept wartet auf einen echten Request und ist erlaubt. Die Regel no-unnecessary-waiting meldet nur Zahlen. Eine feste Zahl wartet immer gleich lang, egal ob die Anwendung an diesem Tag schneller oder langsamer antwortet.

Wie verhindere ich vergessene .only in Tests?

Mit eslint-plugin-mocha. Die Regel mocha/no-exclusive-tests findet .only, mocha/no-pending-tests findet .skip. Setze beide auf error. Dann bricht schon der Lint Job ab, bevor ein halber Testlauf als grüner Build durchgeht. Die README von eslint-plugin-cypress zeigt die passende Kombination beider Plugins.

Kann ich eine Regel für eine Zeile abschalten?

Ja, mit eslint-disable-next-line oder eslint-disable-line und dem Regelnamen, etwa cypress/no-unnecessary-waiting. Nutze das sparsam und immer mit Kommentar, warum. In Teams mit KI Agenten verbieten wir solche Kommentare in der AGENTS.md, damit Agenten Probleme lösen statt sie zu verstecken.

Wie baue ich das Plugin in die CI ein?

Am besten als eigener Job vor dem Cypress Lauf, zum Beispiel mit npx eslint cypress --max-warnings=0. Damit brechen auch Warnungen den Lauf ab. Ein Lint Fehler kostet Sekunden, ein roter E2E Lauf Minuten. In GitLab CI und GitHub Actions ist das jeweils ein kurzer Schritt mit npm ci und dem ESLint Befehl.

Funktioniert das Plugin mit TypeScript?

Ja. Die Regeln laufen auch in TypeScript Dateien, wenn dein Files Pattern ts einschließt. Optional aktivierst du Typed Linting mit @typescript-eslint/parser und projectService. Dann liest der Parser das ganze Projekt, was die Genauigkeit erhöht, aber Laufzeit kostet. Für die meisten Suiten reicht der Standard.