Cypress über das Testen hinaus: Ausführbare Demos für Ihre Pipeline

Verwandeln Sie Ihre Produktvorführungen in Qualitätsprüfungen

13.12.2025, Von Stephan Schwab

Was wäre, wenn jede Produktvorführung gleichzeitig als Qualitätsprüfung in Ihrer CI/CD-Pipeline dienen könnte? Cypress, traditionell als End-to-End-Testwerkzeug positioniert, lässt sich umfunktionieren, um ausführbare Demonstrationen zu erstellen, die sowohl Anwendungsfunktionen für Stakeholder präsentieren als auch kritische Nutzerreisen validieren. Dieser Ansatz liefert doppelten Wert aus einer einzigen Investition und hält dabei Ihre Testpyramide ausgewogen.

Die meisten Teams begegnen Cypress als „noch einem UI-Test-Framework”. Installieren, Selektoren schreiben, Schaltflächen anklicken, Ergebnisse prüfen. Die Dokumentation betont das Testen, die Tutorials konzentrieren sich aufs Testen, und so fügen Teams pflichtbewusst Cypress-Tests zu ihren Suiten hinzu — oft duplizieren sie dabei Abdeckung, die sie bereits auf niedrigeren Ebenen haben.

Es gibt eine wirkungsvollere Art, über Cypress nachzudenken: als Werkzeug zur Erstellung ausführbarer Demonstrationen, die nebenbei auch als Tests fungieren.

Die Testpyramide und wo E2E reingehört

Bevor wir in den Ansatz eintauchen, schauen wir uns die Testpyramide an — ein Konzept, das heute noch genauso relevant ist wie bei seiner Einführung durch Mike Cohn. Die Pyramide legt nahe, dass der Großteil deiner automatisierten Tests schnelle, isolierte Unit-Tests an der Basis sein sollten. Darüber validiert eine kleinere Schicht von Integrationstests, dass Komponenten zusammenarbeiten. Ganz oben bestätigt eine dünne Schicht von E2E-Tests, dass kritische User Journeys durch das gesamte System funktionieren.

        /\
       /  \       E2E-Tests (wenige, langsam, teuer)
      /----\
     /      \     Integrationstests (moderat)
    /--------\
   /          \   Unit-Tests (viele, schnell, günstig)
  --------------

Die Pyramidenform ist Absicht. E2E-Tests sind langsam, flaky und teuer in der Wartung. Sie brauchen den kompletten Stack. Eine einzige Selektor-Änderung kann Dutzende Tests breaken. Teams, die diese Pyramide umdrehen — mehr E2E-Tests als Unit-Tests schreiben — ertrinken oft in Test-Maintenance und shippen trotzdem Bugs.

Warum also überhaupt Cypress? Weil diese wenigen E2E-Tests an der Spitze der Pyramide einen Zweck erfüllen, den Unit- und Integrationstests nicht können: Sie validieren, dass die App so funktioniert, wie ein User sie erleben würde — durch einen echten Browser, mit allen JavaScript-, CSS- und Netzwerk-Interaktionen intakt.

Der Schlüssel liegt darin, strategisch zu entscheiden, was du auf dieser Ebene testest.

Demos als ausführbare Specs

Schau dir den typischen Rhythmus eines Dev-Teams an. Features werden gebaut, und dann muss sie jemand demon — für Product Owner, Stakeholder oder im Sprint Review. Diese Demos folgen einem Script: „Zuerst logge ich mich als Admin ein. Dann navigiere ich zu den Settings. Schaut, wie ich die Notification-Einstellungen update. Seht, wie die Confirmation-Message erscheint.“

Was wäre, wenn dieses Demo-Script ausführbarer Code wäre?

describe('Demo: Benachrichtigungseinstellungen', () => {
  it('ermöglicht einem Administrator die Aktualisierung der Benachrichtigungseinstellungen', () => {
    // Als Administrator authentifizieren
    cy.login('admin@example.com', 'securepassword')
    
    // Zum Einstellungsbereich navigieren
    cy.get('[data-cy="settings-menu"]').click()
    cy.get('[data-cy="notifications-tab"]').click()
    
    // E-Mail-Benachrichtigungseinstellungen aktualisieren
    cy.get('[data-cy="email-notifications-toggle"]')
      .should('be.visible')
      .click()
    
    // Benachrichtigungshäufigkeit anpassen
    cy.get('[data-cy="frequency-dropdown"]').select('Weekly')
    
    // Änderungen speichern
    cy.get('[data-cy="save-preferences"]').click()
    
    // Bestätigung prüfen
    cy.get('[data-cy="success-message"]')
      .should('be.visible')
      .and('contain', 'Preferences saved successfully')
  })
})

Dieser Code macht drei Dinge gleichzeitig:

1. Dokumentiert das Feature so, dass jeder Dev es lesen und verstehen kann
2. Liefert ein Demo-Script, das visuell für Stakeholder ausgeführt werden kann
3. Funktioniert als Quality Gate in deiner CI/CD-Pipeline

Für Stakeholder-Präsentationen laufen die Tests im Headless-Modus mit cypress run — Cypress zeichnet automatisch Videos auf, die du in deinem eigenen Tempo pausieren und kommentieren kannst. Alternativ fügst du cy.pause() an Schlüsselstellen ein; beim Ausführen im interaktiven Modus mit cypress open stoppt die Ausführung an jedem Pause-Punkt, sodass du erklären kannst, was passiert, bevor du auf „Resume“ klickst. Der gleiche Code, der deine Demo bedient, läuft auch in deiner Pipeline, um sicherzustellen, dass dieser kritische User Journey keine Regressionen hat.

Demos schreiben, nicht Tests

Der mentale Shift ist subtil, aber wichtig. Wenn du dir vornimmst, „einen Test zu schreiben“, fokussierst du dich auf Coverage, Edge Cases und Assertions. Wenn du dir vornimmst, „eine Demo zu schreiben“, fokussierst du dich auf den User Journey, die Narrative und die sichtbaren Ergebnisse.

Das verändert, wie du den Code strukturierst:

describe('Order Fulfillment Workflow', () => {
  beforeEach(() => {
    // Setup: ein Kunde hat eine Bestellung aufgegeben
    cy.task('seedOrder', { status: 'pending', items: 3 })
    cy.login('warehouse@example.com')
  })

  it('demonstriert den kompletten Fulfillment-Prozess', () => {
    // Das Warehouse-Team sieht offene Bestellungen auf dem Dashboard
    cy.visit('/fulfillment/dashboard')
    cy.get('[data-cy="pending-orders"]')
      .should('contain', '1 order awaiting fulfillment')

    // Sie öffnen die Order-Details
    cy.get('[data-cy="order-row"]').first().click()
    cy.get('[data-cy="order-items"]')
      .find('li')
      .should('have.length', 3)

    // Jedes Item wird gescannt und als picked markiert
    cy.get('[data-cy="scan-item-input"]').type('SKU-001{enter}')
    cy.get('[data-cy="picked-count"]').should('contain', '1 of 3')
    
    cy.get('[data-cy="scan-item-input"]').type('SKU-002{enter}')
    cy.get('[data-cy="scan-item-input"]').type('SKU-003{enter}')
    cy.get('[data-cy="picked-count"]').should('contain', '3 of 3')

    // Die Order wird als ready for shipping markiert
    cy.get('[data-cy="complete-fulfillment"]').click()
    cy.get('[data-cy="order-status"]')
      .should('contain', 'Ready for Shipping')
  })
})

Schau dir die Kommentare an. Sie lesen sich wie ein Demo-Script, nicht wie Test-Dokumentation. Wenn du das Stakeholdern präsentierst, kannst du die Kommentare buchstäblich vorlesen, während Cypress die Steps ausführt.

Praktische Überlegungen

Nutze Data-Attribute für Selektoren

Widersteh der Versuchung, Elemente über CSS-Klassen oder komplexe DOM-Pfade zu selektieren. Data-Attribute wie data-cy sind explizit, stabil und kommunizieren Intent:

// Fragil - bricht bei Styling-Änderungen
cy.get('.btn.btn-primary.submit-form')

// Robust - übersteht Refactoring
cy.get('[data-cy="submit-order"]')

Erstelle Custom Commands für häufige Actions

Deine Demos werden gemeinsame Patterns haben. Kapsle sie:

// cypress/support/commands.js
Cypress.Commands.add('login', (email, password) => {
  cy.visit('/login')
  cy.get('[data-cy="email-input"]').type(email)
  cy.get('[data-cy="password-input"]').type(password)
  cy.get('[data-cy="login-button"]').click()
  cy.url().should('not.include', '/login')
})

Cypress.Commands.add('addToCart', (productId) => {
  cy.visit(`/products/${productId}`)
  cy.get('[data-cy="add-to-cart"]').click()
  cy.get('[data-cy="cart-notification"]').should('be.visible')
})

Jetzt lesen sich deine Demos noch flüssiger:

it('demonstriert einen kompletten Kaufablauf', () => {
  cy.login('customer@example.com', 'password')
  cy.addToCart('product-123')
  cy.addToCart('product-456')
  cy.visit('/checkout')
  // ...den Journey fortsetzen
})

Halt die Anzahl niedrig

Denk an die Pyramide. Du versuchst nicht, jede Permutation auf E2E-Ebene zu testen. Strebe eine Handvoll Demos an, die die kritischen User Journeys abdecken — die Pfade, die, wenn sie nicht funktionieren, die App unbrauchbar machen oder dem Business signifikante Kosten verursachen würden.

Eine typische App könnte haben:

• 2-3 Demos für den Core-Kauf- oder Conversion-Flow
• 1-2 Demos für Admin-Workflows
• 1 Demo für das User-Onboarding

Das sind vielleicht 5-10 Cypress-Demos insgesamt, nicht 500 E2E-Tests.

Demos in deiner Pipeline laufen lassen

In deiner CI/CD-Config werden diese Demos zum Quality Gate:

# Beispiel GitHub Actions Workflow
cypress-demos:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: cypress-io/github-action@v6
      with:
        start: npm run start:ci
        wait-on: 'http://localhost:3000'
        spec: cypress/e2e/demos/**/*.cy.js

Wenn eine Demo in der Pipeline failt, bedeutet das, dass ein kritischer User Journey kaputt ist. Das ist ein viel stärkeres Signal als „ein Test ist fehlgeschlagen“. Es erzwingt ein Gespräch: „Die Order-Fulfillment-Demo failt — wir können dieses Release nicht shippen, bis das Warehouse-Team Orders abschließen kann.“

Der doppelte Return on Investment

Der traditionelle Ansatz behandelt Demos und Tests als getrennte Aktivitäten. Jemand schreibt Cypress-Tests für die Pipeline. Jemand anderes bereitet PowerPoint-Slides vor und klickt manuell durch die App für Stakeholder. Diese Aktivitäten laufen unabhängig voneinander, kosten Zeit und driften oft auseinander.

Der Ansatz der ausführbaren Demo fasst alles in ein einziges Artefakt zusammen. Die Demo, die du Stakeholdern zeigst, ist derselbe Code, der deine Production-Deploys absichert. Wenn sich die App ändert, updated das Updaten der Demo auch den Test. Wenn Stakeholder fragen „kannst du mir das Feature nochmal zeigen?”, lässt du die Demo laufen — und hast gerade verifiziert, dass sie noch funktioniert.

Es geht nicht darum, ordentliches Testing aufzugeben. Deine Unit-Tests decken weiterhin die Edge Cases ab. Deine Integrationstests verifizieren weiterhin das Zusammenspiel der Komponenten. Die Cypress-Demos sitzen an der Spitze deiner Pyramide und stellen sicher, dass die kritischen Pfade end-to-end funktionieren, während sie gleichzeitig als Kommunikations-Tools für Stakeholder dienen.

Wenn du das nächste Mal zu Cypress greifst, frag dich: Schreibe ich einen Test oder scripte ich eine Demo? Die Antwort könnte verändern, wie du die gesamte Aufgabe angehst.