E2E Test (End-to-End)

Tools: Cypress, Playwright, Selenium. Code (Cypress):

describe('Login', () => {
  it('should log in successfully', () => {
    cy.visit('https://myapp.com');
    cy.get('#username').type('admin');
    cy.get('#password').type('secret');
    cy.get('button.submit').click();
    cy.url().should('include', '/dashboard');
  });
});

Dieser Test startet einen echten Browser und klickt. Du kannst zuschauen.

1. Flakiness (Das Wackel-Problem)

E2E Tests sind notorisch instabil ("Flaky"). Der Test failt, weil:

• Das Netzwerk kurz langsam war (Timeout).
• Die Animation noch nicht fertig war (Element not clickable).
• Die Datenbank noch nicht hochgefahren war. Lösung: Automatic Retries und Smart Waiting. Statt sleep(5000) (Hard Wait) nutzt Cypress waitForElement. Es pollt das DOM, bis das Element da ist.

2. Test Data Management

Woher kommen die User? Strategie A: Mocking. API-Antworten werden gefaked. Schnell, stabil, aber testet nicht das Backend. Strategie B: Seeding. Vor dem Test wird die DB zurückgesetzt und mit Testdaten gefüllt (seed_db.sh). Sicher, aber langsam. Strategie C: Ephemeral Environments. Jeder Test-Run bekommt eine komplett neue Umgebung (Docker Compose / K8s Namespace). Der Gold-Standard.

3. Visual Regression Testing

Ein E2E Test klickt Buttons. Aber er sieht nicht, ob der Button pink statt blau ist. Tools wie Percy oder BackstopJS machen Screenshots und vergleichen sie Pixel für Pixel mit dem "Golden Master". Wenn sich Pixel ändern ("Diff"), schlagen sie Alarm. So findet man CSS-Bugs, die funktionale Tests übersehen.

Network Mocking vs. Spying

Das reine Blackbox-Testing (UI klicken und schauen was passiert) ist oft zu grobkörnig. Moderne E2E-Frameworks (z. B. Playwright, Cypress) können sich tief in den Browser einklinken und den HTTP-Traffic auf Netzwerkebene manipulieren.

• Mocking (Interception): Du blockierst den echten API-Call an den Server und zwingst den Browser, eine vorbereitete JSON-Datei (Fixture) als Antwort zu nutzen (cy.intercept('/api/users', { fixture: 'users.json' })). Das isoliert Frontend-Bugs von flakigen Backends.
• Spying: Du lässt den echten Netzwerk-Call zu, markierst ihn aber mit einem Alias (as('getUsers')). Später im Test wartest du explizit auf die Beendigung dieses Netzwerk-Aufrufs (cy.wait('@getUsers')), bevor du den UI-Zustand abfragst. Das ist die absolute Profilösung für Flakiness, da es Hard-Waits auf DOM-Elemente durch exaktes Warten auf den Netzwerk-Stack ersetzt.

BDD (Behavior-Driven Development) & Gherkin

E2E-Tests sind oft das Bindeglied zwischen Softwareentwicklern und dem Business (Product Owner). Um Business-Anforderungen direkt testbar zu machen, nutzt man das BDD-Pattern mit Tools wie Cucumber und der Sprache Gherkin. Man schreibt Tests in einfachem Englisch/Deutsch:

Feature: Login
  Scenario: Erfolgreicher Login
    Given der User ist auf der Startseite
    When er sich mit "admin" anmeldet
    Then sieht er das Dashboard

Im Code mapst du (als Developer) diese drei Sätze auf konkrete Playwright-Aktionen ("Step Definitions"). Ergebnis: Das Business kann die Test-Dokumentation lesen und versteht exakt, ob die Software die Spezifikation erfüllt (Living Documentation).

Headless vs. Headed (Webkit, Chromium, Firefox)

Für die CI-Pipeline ("Server") führt Playwright die Tests standardmäßig Headless (ohne GUI) aus. Dies eliminiert den enormen Overhead des X11-Window-Servers oder Wayland-Compositors unter Linux und beschleunigt Rendering massiv durch Off-Screen Pufferung. Die Tücke: Manchmal läuft ein Test Headless fehl, ist aber Headed (mit sichtbarem Browserfenster) sofort grün. Dies passiert oft bei Hover-States, GPU-beschleunigten CSS-Animationen (transform: translate) oder komplexen Viewport-Berechnungen (IntersectionObserver), bei denen die Headless-Engine den Render-Tree anders priorisiert oder die Dummy-GPU-Treiber versagen. In solchen Fällen erzwingt man temporär --headed, deaktiviert die Sandbox oder debuggt visuell per "Playwright Trace Viewer" (der jeden DOM-Snapshot der Time-Travel-Aufnahme nachzeichnet).