NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Saatmaschine füllt Datenwürfel in Container, Testdaten in Cypress

Was sind Testdaten in Cypress?

Testdaten in Cypress sind alle Daten, die ein Test braucht, um einen definierten Zustand herzustellen: Nutzer, Produkte, API Antworten oder Datenbankeinträge. Cypress bietet dafür vier Wege, nämlich Fixtures mit cy.fixture, gestubbte Antworten mit cy.intercept, Node Code mit cy.task und API Aufrufe mit cy.request.

Gute Testdaten machen einen Test wiederholbar. Der Test findet bei jedem Lauf denselben Ausgangszustand vor, egal ob er allein läuft, in der Suite oder parallel auf mehreren CI Maschinen. Schlechte Testdaten sind die häufigste Ursache für flaky Tests.

Dazu kommt eine zweite Regel: Testdaten sind immer Fake Daten. Echte Kundendaten haben in Tests nichts zu suchen. Das gilt für deine CI, für Screenshots in der Cloud und für KI Agenten, die gegen deine lokale Umgebung Code schreiben.

Inhalt

Testdaten in Cypress mit NCA: Schnelle Hilfe vom Experten

Cypress mit Cypress Cloud nutzen wir täglich, zusammen mit Symfony, PHPUnit, MySQL, PostgreSQL und SQLite mit libSQL. Roland Golla ist offizieller Cypress Ambassador und arbeitet seit über zwanzig Jahren an Testing und Refactoring. Testdaten sind dabei das Thema, an dem die meisten Suiten scheitern. Wir wissen, wie Fixtures, Seeding und Datenbank Reset zusammenspielen, damit Tests stabil bleiben.

Passend dazu: Faker für realistische Testdaten in der lokalen Entwicklung, der Cypress Workshop mit Roland, die Cypress Remote Schulung für Teams, Schema based AI Coding für saubere Datenmodelle und das Vibe Coding Consulting für Teams mit KI Agenten.

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

Fixtures: feste Daten mit cy.fixture und cy.intercept

Fixtures sind Dateien mit festen Daten, meist JSON. Sie liegen standardmäßig in cypress/fixtures. Du lädst sie mit cy.fixture und nutzt sie für Formulare, Erwartungswerte oder gestubbte API Antworten.

Code: 
          
// cypress/fixtures/products.json
[
  { "id": 1, "name": "Kaffeemühle", "price": 49.9 },
  { "id": 2, "name": "Wasserkocher", "price": 29.9 }
]

Richtig stark werden Fixtures mit cy.intercept. Du fängst einen API Aufruf ab und antwortest mit der Fixture. Das Frontend sieht immer dieselben Daten, unabhängig vom Backend.

Code: 
          
describe('Produktliste', () => {
  it('zeigt alle Produkte aus der API', () => {
    cy.intercept('GET', '/api/products', { fixture: 'products.json' }).as('products')
    cy.visit('/produkte')
    cy.wait('@products')
    cy.get('[data-cy=product]').should('have.length', 2)
    cy.contains('Kaffeemühle').should('be.visible')
  })
})

Wenn du einen Wert für einen Test ändern willst, lädst du die Fixture und passt das Objekt an, statt eine zweite Datei anzulegen. Cypress lädt eine Fixture laut Doku pro Test nur einmal und geht davon aus, dass sie sich nicht ändert. Für Dateien mit mehreren Megabyte ist cy.fixture nicht gedacht.

Grenze von Fixtures: Gestubbte Antworten testen dein Frontend, nicht die echte API. Für den kompletten Weg durch Backend und Datenbank brauchst du echte Daten in der Datenbank. Dafür sind die nächsten beiden Wege da.

cy.task: Datenbank Reset und Seeding in Node

Tests laufen im Browser. Deine Datenbank erreichst du von dort nicht. cy.task schlägt die Brücke: Du definierst in der Cypress Konfiguration Funktionen, die in Node laufen, und rufst sie aus dem Test auf. Dort kannst du Datenbanken leeren, Seeds einspielen oder Dateien lesen.

Code: 
          
// cypress.config.ts
import { defineConfig } from 'cypress'
import { resetDatabase, seedUser } from './cypress/support/db'

export default defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      on('task', {
        async 'db:reset'() {
          await resetDatabase()
          return null
        },
        async 'db:seedUser'(user) {
          return seedUser(user)
        },
      })
    },
  },
})
Code: 
          
describe('Profil bearbeiten', () => {
  beforeEach(() => {
    cy.task('db:reset')
    cy.task('db:seedUser', { email: 'anna@example.test', role: 'editor' })
      .as('user')
  })

  it('speichert einen neuen Anzeigenamen', () => {
    cy.visit('/profil')
    cy.get('[data-cy=display-name]').clear().type('Anna Müller')
    cy.get('[data-cy=save]').click()
    cy.contains('Gespeichert').should('be.visible')
  })
})

Drei Regeln aus der Cypress Doku zu cy.task, die oft übersehen werden:

  • Ein Task darf nie undefined zurückgeben. Gib null zurück, wenn es nichts zu melden gibt.
  • Ein Task bekommt genau ein Argument. Mehrere Werte übergibst du als Objekt.
  • Ein Task muss innerhalb von taskTimeout fertig sein, sonst schlägt der Test fehl.

Setz den Reset in beforeEach, nie in afterEach. Code in after Hooks läuft nicht garantiert, etwa wenn du den Test Runner mitten im Lauf neu lädst. In Symfony Projekten kannst du statt eines eigenen Tasks auch cy.exec mit php bin/console doctrine:fixtures:load --no-interaction aufrufen, wenn das DoctrineFixturesBundle installiert ist.

API Seeding mit cy.request

Der schnellste Weg zu Daten in der App führt über deine eigene API. Mit cy.request schickst du einen HTTP Aufruf direkt aus dem Test, ohne Browser Oberfläche. Ein Login, ein Warenkorb oder ein Artikel ist so mit einem Aufruf angelegt, statt über mehrere Formulare geklickt.

Code: 
          
beforeEach(() => {
  cy.request('POST', '/api/test/articles', {
    title: `Testartikel ${Cypress.spec.name} ${Date.now()}`,
    status: 'draft',
  })
    .its('body.id')
    .as('articleId')
})

it('veröffentlicht einen Entwurf', function () {
  cy.visit(`/admin/artikel/${this.articleId}`)
  cy.get('[data-cy=publish]').click()
  cy.contains('Veröffentlicht').should('be.visible')
})

Worauf du achten musst:

  • Nur in Testumgebungen: Endpunkte zum Anlegen von Testdaten dürfen in Production nicht erreichbar sein. Schalte sie über die Umgebung ab und schütze sie zusätzlich.
  • Fachliche Regeln bleiben aktiv: Wenn du über die echte API seedest, greifen Validierung und Rechte. Das ist ein Vorteil, denn deine Testdaten sind dann gültig.
  • UI nur dort, wo du sie testest: Den Weg durch das Formular testest du einmal gezielt. Alle anderen Tests holen sich ihre Daten per API.

Testdaten Methoden in Cypress im Vergleich

Welcher Weg passt wann, und wo die typischen Fallen liegen.
Methode Wann Achtung
cy.fixture Feste Eingaben und Erwartungswerte, kleine JSON Dateien Wird pro Test einmal geladen, nicht für große Dateien gedacht
cy.intercept mit Fixture Frontend Tests mit stabilen API Antworten, Fehlerfälle simulieren Testet die echte API nicht mit, Fixture muss zum API Schema passen
cy.task Datenbank Reset und Seeding in Node, vor jedem Test Nie undefined zurückgeben, taskTimeout beachten, Reset nie parallel auf geteilter DB
cy.request Schnelles Anlegen über die eigene API, Login ohne UI Test Endpunkte in Production abschalten, eindeutige Werte pro Spec
Faker mit festem Seed Realistische Fake Daten, reproduzierbar Gleicher Seed auf allen Maschinen erzeugt gleiche Werte, eindeutige Felder ergänzen

Faker mit festem Seed: realistisch und reproduzierbar

Feste Werte wie test@test.de finden kaum Fehler. Echte Namen mit Umlauten, lange Straßennamen oder ungewöhnliche Postleitzahlen schon. Dafür gibt es Faker. Wie du Faker installierst, die deutsche Locale nutzt und Seed Skripte baust, steht ausführlich in unserem Artikel Faker: Realistische Testdaten für lokale Entwicklung mit KI.

Für Cypress zählt vor allem ein Punkt: der feste Seed. Ohne Seed erzeugt Faker bei jedem Lauf andere Daten. Ein Test, der heute grün ist, kann morgen an einem Sonderzeichen scheitern, und du kannst den Fehler nicht nachstellen.

Code: 
          
import { faker } from '@faker-js/faker'

beforeEach(() => {
  faker.seed(42)
})

it('legt einen Kunden mit realistischen Daten an', () => {
  const customer = {
    name: faker.person.fullName(),
    city: faker.location.city(),
    email: `${Cypress.spec.name}-${Date.now()}@example.test`,
  }
  cy.request('POST', '/api/test/customers', customer)
})

Achte auf die Mail Adresse im Beispiel. Mit festem Seed erzeugt jede CI Maschine dieselben Werte. Felder, die eindeutig sein müssen, bekommen deshalb einen Anteil aus Spec Name und Zeitstempel. So bleibt der Rest reproduzierbar und Kollisionen bei paralleler Ausführung entfallen.

Testdaten isolieren für parallele Läufe

Sobald deine Suite auf mehreren CI Maschinen parallel läuft, teilen sich oft alle Maschinen eine Testdatenbank. Dann reicht ein globaler Reset nicht mehr. Spec A setzt die Datenbank zurück, während Spec B auf einer anderen Maschine gerade ihren User braucht. Das Ergebnis sind Fehler, die lokal nie auftreten.

Drei Strategien, je nach Setup:

  • Eine Datenbank pro Maschine: Jede CI Instanz startet ihre eigene Datenbank im Container. Dann darfst du vor jedem Test komplett zurücksetzen. Mit SQLite oder einem Datenbank Service pro Job ist das oft am einfachsten.
  • Eigene Daten pro Spec: Bei einer geteilten Datenbank legt jede Spec ihre Daten mit eindeutigen Werten an und liest nur diese. Kein globaler Reset, keine Zählassertions über alle Einträge.
  • Mandant pro Spec: Wenn deine App Mandanten kennt, bekommt jede Spec einen eigenen. Das trennt die Daten sauber und passt zu realen Rechten.

Cypress hilft auf der Browser Seite: Mit aktiver testIsolation, dem Standard seit Cypress 12, werden Seite, Cookies, Local Storage und Session Storage vor jedem Test geleert. Die Datenbank fasst Cypress nicht an. Die ist deine Aufgabe. Wie du Specs auf mehrere Maschinen verteilst, zeigt die Cypress Doku zur Parallelisierung.

Fake Daten statt Kundendaten: DSGVO und KI Agenten

Ein Abzug der Produktionsdatenbank wirkt bequem. Die Daten sind realistisch und schon da. Trotzdem gehören echte Kundendaten nicht in Tests. Sie landen in CI Logs, in Screenshots, in Videos und mit --record auch in Cypress Cloud. Cypress Cloud ist ein US Anbieter. Damit wird jeder Testlauf zu einer Frage für deinen Datenschutz.

Mit KI Agenten in Cypress wird das Thema größer. Ein Coding Agent liest Datenbankinhalte, Logs und Testergebnisse, um Code zu schreiben oder Fehler zu finden. Bei NCA laufen Coding Modelle deshalb gegen lokale Entwicklungsumgebungen mit Fake Daten. Der Agent schreibt Tests, ein Mensch reviewt und gibt frei, und die Quality Gates in CI entscheiden. Mehr dazu in den Guardrails für Agentic AI Coding und bei den Risiken von Vibe Coding.

So setzt du das um:

  • Seed Skripte erzeugen alle Daten, die Entwicklung und Tests brauchen.
  • Mail Adressen nutzen reservierte Domains wie example.test, damit nie eine echte Mail rausgeht.
  • Testdateien und Seeds liegen im Repository und laufen durch dasselbe Review wie Code.
  • Agenten bekommen über Regeln in der AGENTS.md klare Grenzen, welche Daten und Dateien sie anfassen dürfen.

The new command cy.task allows us to do anything.

Gleb Bahmutov, Ehemals VP of Engineering bei Cypress.io – Blog Artikel Incredibly Powerful cy.task

Aus der NCA Praxis: Testdaten zuerst

Wenn eine Suite flaky ist, schauen wir zuerst auf die Testdaten und erst danach auf Selektoren und Wartezeiten. Fast immer findet sich ein Test, der Daten eines anderen nutzt, oder ein Reset an der falschen Stelle. Wir räumen das in kleinen Schritten auf, damit die Suite währenddessen grün bleibt.

Welche Daten ein Test braucht, klären wir mit dem Team per Example Mapping. Die Beispiele landen direkt als Seeds und Fixtures im Repository und werden Teil der lebenden Spezifikation. Für Akzeptanztests, die ein KI Agent vorschlägt, gilt dasselbe Prinzip, wie wir bei den agentischen Akzeptanztests zeigen.

Saubere Testdaten sind auch eine Frage der Pipeline. Unsere Quality Gates für KI Code zeigen, wie statische Analyse, Unit Tests und Cypress E2E zusammenspielen. Wenn KI Agenten die Testergebnisse auswerten sollen, hilft der Cypress Cloud MCP.

Passend dazu im NCA Cypress Glossar: Cypress Custom Commands für wiederverwendbare Seed und Login Abläufe sowie KI Features testen mit Cypress, wo Fixtures LLM Antworten ersetzen.

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 Testdaten in Cypress

Die wichtigsten Antworten zu Fixtures, cy.task, API Seeding und Fake Daten in Cypress Tests.

Wie verwalte ich Testdaten in Cypress 2026 am besten?

Kombiniere mehrere Wege. Fixtures nutzt du für feste Eingaben und gestubbte API Antworten. Mit cy.task setzt du die Datenbank vor jedem Test zurück und spielst Seeds ein. Mit cy.request legst du Daten schnell über deine eigene API an. Faker mit festem Seed liefert realistische Werte. Alle Daten sind Fake Daten und jede Spec erzeugt ihre eigenen.

Was ist der Unterschied zwischen cy.fixture und cy.intercept 2026?

cy.fixture lädt eine Datei mit festen Daten in deinen Test. cy.intercept fängt Netzwerkaufrufe ab und kann mit der Option fixture direkt eine Fixture als Antwort liefern. Zusammen testest du dein Frontend mit stabilen API Antworten, ohne dass das Backend bestimmte Daten haben muss. Die echte API testest du damit allerdings nicht mit.

Wie setze ich 2026 die Datenbank vor Cypress Tests zurück?

Du definierst in setupNodeEvents einen Task, etwa db:reset, der in Node die Datenbank leert und Seeds einspielt. Im Test rufst du ihn mit cy.task in einem beforeEach Hook auf. Wichtig: Der Task gibt null zurück, nie undefined, und er muss innerhalb von taskTimeout fertig sein. Setz den Reset vor den Test, nie danach.

Sollte ich 2026 Testdaten per API oder über die UI anlegen?

Per API, außer du testest genau diesen Weg durch die Oberfläche. Mit cy.request legst du Nutzer, Artikel oder Warenkörbe mit einem Aufruf an. Das spart Zeit und macht Tests unabhängig von Formularen, die gar nicht im Fokus stehen. Das Formular selbst testest du einmal gezielt. Endpunkte nur für Testdaten schaltest du in Production ab.

Wie nutze ich Faker 2026 in Cypress reproduzierbar?

Setz vor jedem Test einen festen Seed mit faker.seed und einer Zahl. Dann erzeugt Faker bei jedem Lauf dieselben Werte und du kannst Fehler nachstellen. Bei paralleler Ausführung bekommen alle Maschinen dieselben Werte. Felder, die eindeutig sein müssen, wie Mail Adressen, ergänzt du deshalb um Spec Name und Zeitstempel.

Warum gibt cy.task einen Fehler bei undefined?

Cypress erwartet von jedem Task einen Rückgabewert, der zeigt, dass der Task fertig ist. Gibt deine Funktion undefined zurück oder löst ein Promise mit undefined auf, schlägt der Befehl fehl. Die Lösung ist einfach: Gib am Ende null zurück, wenn es nichts zu melden gibt. Bei async Funktionen gilt das genauso für den Wert des Promise.

Wie isoliere ich Testdaten für parallele Cypress Läufe?

Am einfachsten bekommt jede CI Maschine ihre eigene Datenbank im Container. Dann darfst du vor jedem Test komplett zurücksetzen. Bei einer geteilten Datenbank legt jede Spec ihre eigenen Daten mit eindeutigen Werten an und liest nur diese. Ein globaler Reset ist dann tabu, denn er löscht Daten, die eine andere Maschine gerade braucht.

Leert Cypress die Datenbank zwischen Tests automatisch?

Nein. Mit aktiver testIsolation, dem Standard seit Cypress 12, leert Cypress vor jedem Test nur den Browser Zustand: Seite, Cookies, Local Storage und Session Storage. Deine Datenbank fasst Cypress nicht an. Den Reset baust du selbst, zum Beispiel mit cy.task oder cy.exec und einem Seed Befehl deines Frameworks in einem beforeEach Hook.

Darf ich echte Kundendaten in Cypress Tests verwenden?

Davon raten wir klar ab. Echte Daten landen in CI Logs, Screenshots, Videos und mit --record auch in Cypress Cloud, einem US Anbieter. Das macht jeden Testlauf zu einem Datenschutz Thema. Fake Daten aus Seed Skripten und Faker sind genauso realistisch, liegen im Repository und lassen sich jederzeit neu erzeugen. Für KI Agenten gilt dieselbe Regel.

Warum brauchen KI Agenten Fake Daten in der lokalen Umgebung?

Coding Agenten lesen Datenbankinhalte, Logs und Testergebnisse, um Code zu schreiben oder Fehler einzugrenzen. Was sie sehen, geht an das Modell. Mit Fake Daten in der lokalen Umgebung kann dabei keine echte Kundenangabe abfließen. Gleichzeitig bekommt der Agent realistische Daten, an denen er Sonderfälle wie Umlaute oder lange Namen erkennt.

Wo lege ich Fixtures in Cypress ab?

Standardmäßig im Ordner cypress/fixtures. Du kannst Unterordner anlegen und sie mit dem Pfad laden, etwa users/admin.json. Lässt du die Dateiendung weg, sucht Cypress in einer festen Reihenfolge nach passenden Dateien, zuerst nach JSON. Große Dateien mit mehreren Megabyte gehören nicht in Fixtures. Dafür nutzt du selectFile oder cy.task.

Wann nutze ich cy.exec statt cy.task für Testdaten?

cy.exec führt einen Shell Befehl aus. Das passt, wenn dein Framework schon einen Befehl für Seeds mitbringt, etwa doctrine:fixtures:load in Symfony mit dem DoctrineFixturesBundle. cy.task nutzt du, wenn du die Logik in Node schreiben willst, Daten zurückbekommen möchtest oder direkt mit einem Datenbank Client arbeitest. Beide gehören in einen beforeEach Hook.