NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Vier grüne Rennbahnen mit Testwürfeln nebeneinander, Parallelisierung

Was ist Cypress Parallelisierung?

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 ganze Spec Dateien, keine einzelnen Tests.

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.

Inhalt

Cypress Parallelisierung mit NCA: Schnelle Hilfe vom Experten

Cypress mit Cypress Cloud läuft bei uns täglich in Production, in GitHub Actions und GitLab CI. Roland Golla ist offizieller Cypress Ambassador und arbeitet seit über zwanzig Jahren an Testing und Refactoring. Automatisiert testen wir bei NCA seit 2013. Wir kennen die typischen Bremsen einer langen Suite: Specs, die voneinander abhängen, Testdaten, die sich überschreiben, und Pipelines, die Maschinen verschwenden.

Passend dazu: der Cypress Workshop mit Roland für Teams, die ihre Suite selbst aufbauen, die Cypress Remote Schulung für Teams, unsere Quality Gates für KI Code in der Pipeline, das Vibe Coding Consulting für Teams mit KI Agenten und der Cypress Cloud MCP, über den Agenten deine Testläufe lesen.

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

So funktioniert cypress run mit --record und --parallel

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.

Code: 
          
npx cypress run --record --key $CYPRESS_RECORD_KEY --parallel --group e2e-chrome --browser chrome

Die wichtigsten Flags im Überblick:

  • --record: Pflicht. Ergebnisse gehen an Cypress Cloud, die den Lauf koordiniert.
  • --parallel: aktiviert die Verteilung auf alle Maschinen mit derselben Build ID.
  • --group: fasst Läufe unter einem Namen zusammen, zum Beispiel pro Browser.
  • --ci-build-id: nur nötig, wenn Cypress die Build ID deines CI Anbieters nicht selbst erkennt.

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.

Smart Orchestration: Load Balancing, Spec Priorisierung, Auto Cancellation

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.

Load Balancing verteilt deine Specs nicht stumpf nach Anzahl. Cypress schätzt 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:

  • Spec Priorisierung: Specs, die im letzten Lauf fehlgeschlagen sind, laufen zuerst. Du siehst schnell, ob dein Fix wirkt. Aktivierung in den Project Settings unter Smart Orchestration.
  • Auto Cancellation: Cypress bricht einen Lauf ab, sobald eine Zahl fehlgeschlagener Tests erreicht ist. Standard ist 1. Flaky Tests zählen dabei nicht. Pro Lauf kannst du den Wert mit --auto-cancel-after-failures überschreiben.

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.

Cypress Cloud Funktionen für parallele Läufe

Stand laut Cypress Doku und Pricing Seite. Plan Grenzen ändern sich, prüf sie vor der Planung.
Funktion Was sie macht Plan
Parallelisierung Verteilt Spec Dateien auf mehrere CI Maschinen, braucht --record und --parallel Ab Starter
Load Balancing Ordnet Specs nach geschätzter Laufzeit aus früheren Läufen, pro Browser Ab Team
Spec Priorisierung Startet Specs, die im letzten Lauf fehlgeschlagen sind, zuerst Business, Enterprise
Auto Cancellation Bricht den Lauf nach einer Zahl echter Fehlschläge ab, Flaky Tests zählen nicht Business, Enterprise
--group Bündelt mehrere cypress run Aufrufe unter einem Namen in einem Lauf Mit --record

GitHub Actions: Matrix mit Cypress Cloud

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.

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

  • fail-fast: false: Ohne diese Zeile bricht GitHub alle Jobs ab, sobald einer rot wird. Die Cypress Prozesse sterben dann mitten im Lauf und Cypress Cloud wartet vergeblich.
  • Record Key als Secret: Der Key gehört in die Repository Secrets, nie in die Konfiguration.
  • GITHUB_TOKEN: hilft Cypress, Re Runs eines Workflows sauber als neuen Lauf zu erkennen.

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: das parallel Keyword

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.

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

  • Lege CYPRESS_RECORD_KEY als maskierte CI/CD Variable in den Projekteinstellungen an.
  • Der separate install Job füllt den Cache, den alle parallelen Jobs danach nutzen.
  • Mit parallel: 4 bekommst du vier Instanzen. Jede braucht einen freien Runner, sonst warten sie in der Queue.

Wer Pipelines mit KI Agenten steuert, findet beim glab GitLab CLI MCP Server den passenden Zugang zu Jobs und Logs.

Testisolation: die Voraussetzung für parallele Läufe

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:

  • Gemeinsame Datensätze: Zwei Maschinen ändern denselben User oder dieselbe Bestellung. Einer der Tests wird rot.
  • Datenbank Reset mitten im Lauf: Eine Spec setzt die Datenbank zurück, während eine andere Maschine noch darauf testet.
  • Feste Reihenfolge: Eine Spec erwartet Daten, die eine andere erst erzeugt.
  • Globale Zähler und Mails: Assertions auf Anzahl Einträge oder auf das letzte Mail im Postfach brechen, wenn andere Maschinen parallel schreiben.

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, nie danach. 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.

CI Kosten, Laufzeit und Datenschutz ehrlich einordnen

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:

  • Miss die Laufzeit seriell und mit zwei, drei und vier Maschinen.
  • Schau in Cypress Cloud, ob einzelne Specs den Lauf dominieren. Eine sehr lange Spec teilst du besser in mehrere Dateien.
  • Cache Abhängigkeiten und das Cypress Binary, damit der Overhead pro Maschine klein bleibt.
  • Nutze Auto Cancellation, wenn dein Plan sie enthält. Ein Lauf mit klarem Fehler muss nicht zu Ende laufen.

Ein Wort zum Datenschutz: Cypress Cloud ist ein US Anbieter. Mit --record landen Testergebnisse, Screenshots und je nach Einstellung Videos und Test Replay Daten dort. Teste deshalb gegen Umgebungen mit Fake Daten und nie mit echten Kundendaten. 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.

Für Teams mit KI Agenten in Cypress gehört die Pipeline zu den Guardrails für Agentic AI Coding: Der Agent schreibt Tests, ein Mensch reviewt und gibt frei, und erst die grüne Pipeline mit statischer Analyse, Unit Tests und Cypress E2E entscheidet über den Merge.

By putting longer specs first, we can achieve faster completion times.

Gleb Bahmutov, Cypress.io – Cypress Blog

Aus der NCA Praxis: parallel heißt isoliert

Wenn wir eine bestehende Suite parallelisieren, starten wir selten mit der CI Konfiguration. Die ist schnell geschrieben. Die eigentliche Arbeit steckt in den Specs: Abhängigkeiten finden, Testdaten pro Spec erzeugen und den Reset vor jeden Test ziehen. Erst danach drehen wir die Zahl der Maschinen hoch.

Bei Legacy Projekten sichern wir das Verhalten zuerst ab und räumen dann auf. Fachliche Tests erarbeiten wir mit dem Team per Example Mapping und halten sie als lebende Spezifikation aktuell. Wer Selenium Suiten ablösen will, findet im Glossar die Einordnung zu Selenium.

Für Teams, die Testing mit KI Agenten neu aufstellen, kombinieren wir Cypress Know how mit der KI Weiterbildung für Entwicklerteams. Barrierefreiheit prüfen wir in derselben Pipeline mit axe DevTools und Cypress.

Passend dazu im NCA Cypress Glossar: Cypress UI Coverage zeigt, welche Bereiche deine parallel laufende Suite noch nicht abdeckt.

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 Cypress Parallelisierung

Die wichtigsten Antworten zu parallelen Cypress Läufen, Cypress Cloud Plänen und der Einrichtung in GitHub Actions und GitLab CI.

Wie funktioniert Cypress Parallelisierung 2026?

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, Cypress teilt also ganze Spec Dateien zu und keine einzelnen Tests. Alle Maschinen mit derselben Build ID gehören zum selben Lauf.

Brauche ich 2026 Cypress Cloud für parallele Cypress Tests?

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.

Welche Cypress Cloud Pläne enthalten 2026 Load Balancing und Auto Cancellation?

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.

Wie viele CI Maschinen sind 2026 für Cypress sinnvoll?

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.

Wie richte ich 2026 Cypress Parallelisierung in GitHub Actions ein?

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.

Wie parallelisiere ich Cypress in GitLab CI?

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.

Was ist Load Balancing in Cypress Cloud?

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.

Warum werden meine Cypress Tests parallel flaky?

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, nie danach.

Was macht das Flag --group bei Cypress?

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.

Was ist Spec Priorisierung 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.

Ist Cypress Cloud DSGVO konform nutzbar?

Cypress Cloud ist ein US Anbieter. Mit --record landen Testergebnisse, Screenshots und je nach Einstellung Videos und Test Replay Daten dort. Die rechtliche Bewertung musst du mit deinem Datenschutz klären. Technisch hilft eine klare Regel: Tests laufen gegen Umgebungen mit Fake Daten, nie gegen echte Kundendaten. Dann landen auch keine Kundendaten in der Cloud.

Spart Parallelisierung CI Kosten?

Parallelisierung spart Wartezeit, nicht automatisch Rechenzeit. 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, mit Auto Cancellation bei klaren Fehlern und mit gut geschnittenen Specs. Und schnelleres Feedback spart deinem Team Zeit beim Warten auf die Pipeline.