Cypress Parallelisierung verteilt deine Spec Dateien auf mehrere CI Maschinen, die gleichzeitig laufen. Cypress Cloud koordiniert den Lauf und gibt jeder freien Maschine die nächste Spec Datei, bis alle Tests durch sind.
Du startest das mit cypress run --record --parallel auf jeder Maschine. Ohne --record geht es nicht, denn die Verteilung braucht einen zentralen Dienst. Die Strategie ist dateibasiert: Cypress verteilt immer ganze Spec Dateien. Alle Tests einer Datei laufen auf derselben Maschine.
Für Teams mit großer Suite heißt das: kürzere Wartezeit auf grünes Licht in der Pipeline. Das klappt aber nur, wenn jede Spec Datei für sich allein läuft. Shared State, feste Reihenfolgen und gemeinsame Testdaten werden bei paralleler Ausführung sofort sichtbar. Darum geht es auf dieser Seite genauso wie um die CI Konfiguration.
Wenn ein Team seine Suite parallelisieren will, ist die Konfiguration in GitHub Actions oder GitLab CI schnell geschrieben. Die eigentliche Arbeit steckt in den Specs. Wir suchen Specs, die heimlich voneinander abhängen, geben jeder Spec eigene Testdaten und ziehen den Reset vor den Test. Erst dann bringen mehr Maschinen echten Zeitgewinn. Cypress mit Cypress Cloud läuft bei uns täglich in Production, und Roland Golla ist offizieller Cypress Ambassador.
Mit deinem Team gehen wir die Suite Spec für Spec durch, lösen versteckte Abhängigkeiten und richten die parallele Pipeline ein. Das Wissen dazu baut ihr im Cypress Workshop mit Roland Golla direkt an eurem Code auf, remote geht das in der Cypress Remote Schulung für Teams. Saubere Testdaten in Cypress sind der erste Schritt, eine Smoke Stufe mit Cypress Grep der zweite. Die Pipeline ergänzen wir um Quality Gates für KI Code, und für Teams mit KI Agenten kommt die Vibe Coding Beratung dazu.
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.
Ohne Parallelisierung arbeitet cypress run alle Spec Dateien nacheinander ab. Mit Parallelisierung startest du denselben Befehl auf mehreren Maschinen. Jede Maschine meldet sich bei Cypress Cloud und holt sich die nächste Spec Datei aus einer gemeinsamen Warteschlange.
npx cypress run --record --key $CYPRESS_RECORD_KEY --parallel --group e2e-chrome --browser chrome
Die wichtigsten Flags im Überblick:
Cypress erkennt die Build ID bei gängigen Anbietern wie GitHub Actions, GitLab CI, Jenkins oder CircleCI automatisch über Umgebungsvariablen. So wissen alle Maschinen, dass sie zum selben Lauf gehören. Wichtig: Die Reihenfolge der Spec Dateien ist bei paralleler Ausführung laut Cypress Doku nicht garantiert. Dein Test darf sich also nie darauf verlassen, dass eine andere Spec vorher lief.
Cypress fasst die Funktionen rund um parallele Läufe in der Cloud unter dem Namen Smart Orchestration zusammen. Der wichtigste Teil ist das Load Balancing. Es startet automatisch, sobald du mit --record und --parallel arbeitest.
Beim Load Balancing schätzt Cypress die Laufzeit jeder Spec Datei aus früheren Läufen, getrennt pro Browser. Jede Maschine zieht sich die nächste Spec aus einer geordneten Warteschlange, sobald sie frei ist. So wartet keine Maschine lange auf eine andere. Specs mit ähnlicher Laufzeit lassen sich laut Doku am besten parallelisieren.
Zwei weitere Funktionen helfen beim Debuggen:
Laut Cypress Doku sind Spec Priorisierung und Auto Cancellation Teil der Business und Enterprise Pläne. Prüf vor der Planung, welche Funktionen dein Plan enthält. Die Tabelle unten fasst den Stand zusammen.
In GitHub Actions baust du die Maschinen über eine Matrix. Jeder Matrix Eintrag startet einen eigenen Job. Die offizielle Cypress GitHub Action übernimmt Installation, Cache und den Aufruf mit den richtigen Flags.
name: E2E Tests
on: push
jobs:
cypress:
runs-on: ubuntu-24.04
strategy:
fail-fast: false
matrix:
containers: [1, 2, 3]
container:
image: cypress/browsers:latest
options: --user 1001
steps:
- name: Checkout
uses: actions/checkout@v7
- name: Cypress run
uses: cypress-io/github-action@v7
with:
record: true
parallel: true
group: 'E2E Chrome'
browser: chrome
env:
CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Drei Punkte entscheiden über einen stabilen Lauf:
Die Zahl der Container ist dein Hebel. Mehr Einträge heißt mehr parallele Maschinen. Starte klein, schau dir die Laufzeiten in Cypress Cloud an und erhöhe dann. Wenn KI Agenten deine Workflows anfassen, hilft der GitHub MCP Server beim Lesen von Pipelines und Runs.
GitLab CI macht es noch kürzer. Das Keyword parallel startet denselben Job mehrfach. Cypress erkennt die Pipeline ID von GitLab selbst, alle Instanzen landen im selben Lauf. Das Beispiel folgt dem Aufbau aus der Cypress Doku für GitLab CI.
stages:
- build
- test
variables:
npm_config_cache: '$CI_PROJECT_DIR/.npm'
CYPRESS_CACHE_FOLDER: '$CI_PROJECT_DIR/cache/Cypress'
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- .npm
- cache/Cypress
- node_modules
install:
image: cypress/browsers:latest
stage: build
script:
- npm ci
e2e-chrome:
image: cypress/browsers:latest
stage: test
parallel: 4
script:
- npm ci
- npm start &
- npx cypress run --record --parallel --browser chrome --group e2e-chrome
Ein paar Hinweise aus der Praxis:
Wer Pipelines mit KI Agenten steuert, findet beim glab GitLab CLI MCP Server den passenden Zugang zu Jobs und Logs.
Parallelisierung deckt jede versteckte Abhängigkeit auf. Seriell lief Spec B vielleicht nur grün, weil Spec A vorher einen User angelegt hat. Parallel fehlt dieser User plötzlich. Die Cypress Doku formuliert die Regel klar: Jeder Test muss unabhängig von anderen laufen und bestehen.
Typische Probleme bei paralleler Ausführung:
Die Lösung beginnt bei den Testdaten. Jede Spec erzeugt ihre eigenen Daten mit eindeutigen Werten, etwa einer Run ID im Namen oder der Mail Adresse. Den Zustand setzt du vor dem Test zurück, denn Hooks in after laufen nicht garantiert. Realistische Fake Daten mit festem Seed liefert Faker für lokale Entwicklung und Tests.
Ein schneller Check: Setz bei einem Test it.only und starte ihn allein. Läuft er grün, ist er isoliert. Fällt er durch, hängt er an einer anderen Spec. Diese Disziplin zahlt sich auch für agentische Akzeptanztests aus, bei denen ein KI Agent Tests schreibt und du sie reviewst.
Parallelisierung senkt die Wartezeit. Die Rechenzeit sinkt dabei nicht automatisch. Jede zusätzliche Maschine startet einen Container, installiert Abhängigkeiten und bootet die App. Dieser Overhead fällt pro Maschine an. Ab einem Punkt bringt eine weitere Maschine kaum noch Zeit, kostet aber weiter CI Minuten.
So findest du den Punkt für dein Projekt:
Noch früher sparst du mit einer Smoke Stufe. Mit Cypress Grep läuft vorher eine kurze Auswahl getaggter Tests auf einer Maschine. Erst wenn sie grün ist, startet die volle Suite parallel. Ein kaputter Build blockiert dann keine ganze Matrix.
Mit --record landen Testergebnisse, Screenshots und je nach Einstellung Videos und Test Replay Daten in Cypress Cloud. Weil Cypress Cloud ein US Anbieter ist, gehören nur Fake Daten in deine Tests, mehr dazu unter Testdaten in Cypress.
Wer ohne externen Dienst parallelisieren will, findet Community Plugins wie cypress-split von Gleb Bahmutov. Es teilt die Specs vor dem Start auf die CI Maschinen auf. Die dynamische Warteschlange von Cypress Cloud, Spec Priorisierung und Auto Cancellation bekommst du damit nicht.
Schreiben KI Agenten deine Tests, wird diese Pipeline zum Teil der Guardrails für Agentic AI Coding, die Regeln dazu stehen unter Cypress mit KI Agenten.
By putting longer specs first, we can achieve faster completion times.
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
Quality Gates für KI generierten Code: Linting, Tests, Review Agents und CI Pipelines setzen CLAUDE.md Regeln automatisch durch. Praxiswissen von NCA
Mehr erfahrenBeim Parallelisieren einer bestehenden Suite gehen wir in fester Reihenfolge vor. Zuerst prüfen wir jeden Test einzeln. Dann bekommt jede Spec eigene Testdaten und einen Reset vor dem Test. Erst danach drehen wir die Zahl der Maschinen hoch und schauen in Cypress Cloud, welche Spec den Lauf bremst.
Bei Legacy Projekten sichern wir das Verhalten zuerst ab. Fachliche Tests erarbeiten wir per Example Mapping und halten sie als lebende Spezifikation aktuell. Barrierefreiheit prüfen wir in derselben Pipeline mit axe DevTools und Cypress, die Ablösung alter Suiten ordnen wir unter Selenium ein, und Teams mit KI Agenten begleiten wir in der KI Weiterbildung für Entwicklerteams. Welche Bereiche deine parallele Suite noch nicht abdeckt, zeigt Cypress UI Coverage im NCA Cypress Glossar.
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 Antworten zu parallelen Cypress Läufen, Cypress Cloud Plänen und der Einrichtung in GitHub Actions und GitLab CI.
Du startest cypress run mit --record und --parallel auf mehreren CI Maschinen gleichzeitig. Cypress Cloud koordiniert den Lauf und gibt jeder freien Maschine die nächste Spec Datei aus einer gemeinsamen Warteschlange. Die Verteilung ist dateibasiert, alle Tests einer Spec Datei laufen also auf derselben Maschine. Alle Maschinen mit derselben Build ID gehören zum selben Lauf.
Für die eingebaute Parallelisierung mit --parallel ja, denn sie braucht --record und damit Cypress Cloud als zentralen Koordinator. Laut Pricing Seite ist Parallelisierung ab dem Starter Plan enthalten. Ohne Cloud kannst du Community Plugins wie cypress-split nutzen. Sie teilen die Specs vor dem Start auf die Maschinen auf, ohne dynamische Warteschlange und ohne Cloud Funktionen wie Spec Priorisierung.
Laut Cypress Pricing Seite gibt es Parallelisierung ab Starter, Load Balancing ab dem Team Plan. Spec Priorisierung und Auto Cancellation sind Teil der Business und Enterprise Pläne. Plan Grenzen können sich ändern. Prüf deshalb vor der Planung die aktuelle Übersicht von Cypress und die Einstellungen deines Projekts in Cypress Cloud unter Smart Orchestration.
Das hängt von deiner Suite ab. Miss die Laufzeit seriell und dann mit zwei, drei und vier Maschinen. Jede Maschine bringt Overhead für Container Start, Installation und App Boot mit. Ab einem Punkt sinkt die Wartezeit kaum noch, die CI Minuten steigen aber weiter. Specs mit ähnlicher Laufzeit lassen sich am besten verteilen.
Du nutzt eine Matrix in der strategy, etwa containers mit drei Einträgen. Jeder Eintrag startet einen Job mit der offiziellen Cypress GitHub Action und den Optionen record und parallel. Setz fail-fast auf false, sonst bricht GitHub alle Jobs beim ersten Fehler ab. Den Record Key und das GITHUB_TOKEN übergibst du als Umgebungsvariablen aus den Secrets.
Du setzt im Test Job das Keyword parallel mit der gewünschten Zahl an Instanzen. Jede Instanz ruft npx cypress run mit --record und --parallel auf. Cypress erkennt die Pipeline ID von GitLab selbst und fasst alle Instanzen zu einem Lauf zusammen. Den Record Key legst du als maskierte CI/CD Variable an. Ein separater install Job füllt den Cache.
Load Balancing ordnet deine Specs nach geschätzter Laufzeit. Cypress Cloud nutzt dafür Daten aus früheren Läufen, getrennt pro Browser. Jede Maschine zieht sich die nächste Spec aus der Warteschlange, sobald sie frei ist. So bleibt keine Maschine lange untätig, während eine andere noch an einer langen Spec arbeitet. Es startet automatisch mit --record und --parallel.
Meist hängen Specs voneinander ab. Eine Spec erwartet Daten, die eine andere vorher angelegt hat, oder zwei Maschinen ändern denselben Datensatz. Bei paralleler Ausführung ist die Reihenfolge der Specs nicht garantiert. Die Lösung: Jede Spec erzeugt ihre eigenen Testdaten mit eindeutigen Werten und setzt den Zustand vor dem Test zurück, weil after Hooks nicht garantiert laufen.
Mit --group fasst du mehrere cypress run Aufrufe unter einem Namen in einem Lauf zusammen. Typisch ist eine Gruppe pro Browser, etwa e2e-chrome und e2e-firefox. In Cypress Cloud siehst du die Ergebnisse dann getrennt nach Gruppe, aber im selben Lauf. Das Flag braucht --record, denn die Gruppen entstehen in Cypress Cloud.
Spec Priorisierung startet die Specs zuerst, die im letzten Lauf fehlgeschlagen sind. Du siehst so nach wenigen Minuten, ob dein Fix wirkt, und musst nicht auf den ganzen Lauf warten. Die übrigen Specs behalten ihre Reihenfolge aus dem Load Balancing. Ein Admin aktiviert die Funktion in den Project Settings unter Smart Orchestration.
Die rechtliche Bewertung klärst du mit deinem Datenschutz, denn Cypress Cloud ist ein US Anbieter. Mit --record landen Testergebnisse, Screenshots und je nach Einstellung Videos und Test Replay Daten dort. In jedem Fall gehören nur Fake Daten in deine Tests, damit keine Kundendaten in der Cloud landen.
Parallelisierung spart Wartezeit. Die Rechenzeit sinkt dabei nicht automatisch, denn jede Maschine bringt eigenen Overhead mit, also können die CI Minuten sogar leicht steigen. Kosten sparst du an anderer Stelle: mit Cache für Abhängigkeiten, einer Smoke Stufe vor dem parallelen Lauf, Auto Cancellation bei klaren Fehlern und gut geschnittenen Specs. Schnelleres Feedback spart deinem Team Wartezeit.
