Die Testpyramide: Wo E2E-Tests wirklich hingehören

1. Die Testpyramide im Überblick

Die Testpyramide wurde von Mike Cohn Ende der 2000er Jahre als einfaches Denkmodell eingeführt und ist bis heute die zentrale Orientierungshilfe für die Struktur einer Testsuite. Das Grundprinzip: Auf der breiten Basis stehen viele schnelle Unit-Tests, in der Mitte eine kleinere Anzahl Integrationstests, und an der Spitze nur wenige End-to-End-Tests, die das System als Ganzes durch die Benutzeroberfläche prüfen. Diese Form ist kein Zufall, sondern spiegelt einen direkten Zusammenhang zwischen Testebene, Ausführungsgeschwindigkeit und Wartungsaufwand wider. Je näher ein Test an der echten Nutzeroberfläche und der vollständigen Systemumgebung liegt, desto teurer wird jeder einzelne Testlauf, sowohl in Rechenzeit als auch in Wartungsstunden, wenn sich die Oberfläche oder externe Abhängigkeiten ändern. Für Teams, die Cypress oder Playwright einführen, ist die Pyramide deshalb kein akademisches Konzept, sondern ein praktisches Werkzeug, um zu entscheiden, wo genau eine neue Testfallidee tatsächlich hingehört, bevor sie unreflektiert als weiterer Cypress-Test in die Suite wandert.

In der Praxis entsteht häufig das Gegenteil der Pyramide, das sogenannte Ice-Cream-Cone-Antipattern: viele E2E-Tests, wenige Integrationstests und kaum Unit-Tests. Der Grund ist meist organisatorisch, nicht technisch. E2E-Tests mit Cypress oder Playwright fühlen sich für Teams unter Zeitdruck sicherer an, weil sie den kompletten Nutzerpfad durch die reale Anwendung abbilden und damit intuitiv mehr Vertrauen erzeugen als ein isolierter Funktionstest. Wird jede neue Anforderung direkt mit einem weiteren Browser-Test abgesichert, wächst die Testsuite zwar in der Abdeckung, aber die Ausführungszeit der Pipeline explodiert, und die Fehlerursache bei einem roten Test lässt sich kaum noch eingrenzen. Die Testpyramide ist die Korrektur zu genau diesem Muster: Sie verlangt, dass Vertrauen so weit wie möglich unten in der Pyramide erzeugt wird, wo Tests günstig und schnell sind, und E2E-Tests nur dort eingesetzt werden, wo sie tatsächlich unersetzbar sind.

2. Die drei Ebenen: Unit, Integration, E2E

Ein Unit-Test prüft eine einzelne Funktion, Methode oder Klasse vollständig isoliert von ihrer Umgebung. Alle externen Abhängigkeiten wie Datenbank, Dateisystem, Netzwerk oder andere Module werden durch Mocks, Stubs oder Fakes ersetzt. Mit Jest oder Vitest läuft ein solcher Test in Millisekunden, ohne dass ein Prozess außerhalb des Testrunners gestartet wird. Ein Integrationstest hingegen prüft das Zusammenspiel mehrerer realer Komponenten, etwa ob ein Service korrekt gegen eine echte, isolierte Testdatenbank schreibt oder ob ein HTTP-Endpunkt mit Supertest die erwartete Antwort liefert. Hier wird bewusst weniger gemockt, weil genau die Integration zwischen den Teilen das Testziel ist.

Ein E2E-Test schließlich simuliert einen realen Nutzer, der über die tatsächliche Oberfläche mit der vollständigen Anwendung interagiert, meist über einen echten Browser, gesteuert durch Cypress oder Playwright. Er durchläuft dieselben Klicks, Formulareingaben und Seitenwechsel wie ein Mensch und prüft damit nicht nur einzelne Komponenten, sondern das Zusammenspiel von Frontend, Backend, Datenbank, Drittanbieter-Diensten und Infrastruktur in einem einzigen Durchlauf. Die Grenzen zwischen den Ebenen sind in der Praxis nicht immer scharf. Komponententests im Browser, Contract-Tests zwischen Services und API-Tests ohne UI liegen oft zwischen Integration und E2E. Entscheidend ist nicht die exakte Kategorisierung, sondern die Frage, wie viele reale Abhängigkeiten ein Test tatsächlich braucht, um sein Ziel zu erreichen.

3. Kosten und Ausführungsgeschwindigkeit je Ebene

Der Kostenunterschied zwischen den Ebenen ist in der Praxis enorm und meistens unterschätzt. Eine Suite mit tausend Unit-Tests läuft mit Vitest oder Jest häufig in unter zehn Sekunden durch, weil kein Prozess außerhalb des Testrunners gestartet wird und jeder Test nur wenige Codepfade durchläuft. Hundert Integrationstests gegen eine echte Testdatenbank oder einen containerisierten Service brauchen dagegen schon ein bis drei Minuten, weil Verbindungsaufbau, Transaktionen und Cleanup pro Test reale Zeit kosten. Zehn E2E-Tests mit Cypress oder Playwright, die jeweils einen Browser starten, eine Seite laden und auf asynchrone Netzwerkantworten warten, können allein schon mehrere Minuten beanspruchen, selbst bei paralleler Ausführung auf mehreren CI-Runnern.

Diese Zeitkosten multiplizieren sich mit der Häufigkeit der Ausführung. Unit-Tests laufen bei jedem Speichern im Watch-Modus und bei jedem Commit, Integrationstests meist bei jedem Push, E2E-Tests oft nur vor einem Deployment oder nachts, weil ihre Laufzeit und Infrastrukturkosten eine Ausführung bei jeder Codeänderung unpraktikabel machen. Wer diese Realität ignoriert und versucht, jede Anforderung mit einem E2E-Test abzusichern, verlangsamt den Entwicklungs-Feedback-Loop so stark, dass Entwickler die CI-Pipeline meiden oder Tests lokal gar nicht mehr ausführen. Ein bewusstes Zeitbudget pro Testebene, das im Skript unten sichtbar wird, macht diese Kosten explizit und erzwingt eine Priorisierung, die sonst implizit und zufällig geschieht.

#!/usr/bin/env bash
# run-tests.sh - Run test suites tier by tier, fail fast on the cheapest tier first
set -euo pipefail

echo "==> Tier 1: Unit tests (Vitest, target: < 10s)"
npx vitest run --coverage || { echo "Unit tests failed, aborting before slower tiers"; exit 1; }

echo "==> Tier 2: Integration tests (Supertest + test DB, target: < 2min)"
npx dotenv -e .env.test -- npx jest --config jest.integration.config.js || {
  echo "Integration tests failed, aborting before E2E tier"; exit 1;
}

echo "==> Tier 3: E2E tests (Playwright, target: < 5min, critical paths only)"
npx playwright test --grep "@critical" || {
  echo "E2E smoke suite failed"; exit 1;
}

echo "All tiers passed"

4. Aussagekraft und Vertrauen: Was jede Ebene wirklich zeigt

Jede Testebene beantwortet eine andere Frage, und diesen Unterschied zu verwechseln ist die häufigste Ursache für falsches Vertrauen in eine Testsuite. Ein Unit-Test beantwortet die Frage, ob eine isolierte Funktion bei gegebenen Eingaben das richtige Ergebnis liefert. Er sagt nichts darüber aus, ob diese Funktion korrekt in das Gesamtsystem eingebunden ist, ob die Datenbankabfrage, die sie aufruft, tatsächlich existiert, oder ob die Route, die sie bedient, überhaupt erreichbar ist. Ein Integrationstest beantwortet die Frage, ob mehrere reale Komponenten korrekt zusammenarbeiten, etwa ob ein Service-Layer die richtigen SQL-Abfragen erzeugt und die Datenbank die erwarteten Daten zurückgibt.

Ein E2E-Test beantwortet eine dritte, andere Frage: Kann ein echter Nutzer eine bestimmte Aufgabe von Anfang bis Ende erfolgreich durchführen? Diese Frage hat die höchste Aussagekraft für das Geschäftsergebnis, aber die geringste diagnostische Präzision. Schlägt ein Checkout-E2E-Test fehl, weiß man, dass irgendetwas im Bestellprozess kaputt ist, aber nicht, ob die Ursache im Frontend, im Payment-Service, in der Datenbank oder in einem Drittanbieter-API liegt. Ein Unit-Test, der an derselben Stelle fehlschlägt, zeigt sofort die exakte Codezeile. Die Testpyramide optimiert genau dieses Verhältnis: maximale diagnostische Präzision und Geschwindigkeit unten, maximale Nutzerrealität und Geschäftsrelevanz oben, mit einem bewussten Gleichgewicht dazwischen.

5. Unit-Tests als Fundament

Unit-Tests bilden das Fundament der Pyramide, weil sie das beste Verhältnis von Ausführungsgeschwindigkeit zu diagnostischer Präzision liefern. Mit Vitest oder Jest lässt sich reine Geschäftslogik, etwa Preisberechnungen, Validierungsregeln oder Formatierungsfunktionen, ohne jede externe Abhängigkeit testen. Der Watch-Modus dieser Testrunner führt betroffene Tests bei jeder Dateiänderung in Millisekunden erneut aus und liefert damit einen Feedback-Loop, der eng genug ist, um testgetrieben zu entwickeln. Entscheidend für die Qualität dieser Ebene ist, dass Abhängigkeiten konsequent über Dependency Injection oder Interfaces austauschbar gehalten werden, damit Mocking nicht zu Verrenkungen im Produktionscode führt, nur um Tests zu ermöglichen.

Gute Unit-Tests decken vor allem Randfälle ab, die in Integrations- oder E2E-Tests praktisch nie systematisch geprüft werden: negative Zahlen, leere Arrays, Null-Werte, Rundungsfehler, Grenzwerte bei Rabattstaffeln. Genau diese Fälle sind in der Praxis häufige Fehlerquellen, weil sie im normalen Entwicklungsfluss selten manuell getestet werden. Werkzeuge wie Mutationstests mit Stryker zeigen zusätzlich, ob die Unit-Test-Suite tatsächlich Fehler erkennt oder nur Code ausführt, ohne echte Assertions zu treffen, denn reine Codeabdeckung in Prozent sagt nichts über die Qualität der Prüfungen aus.

// discount.test.js - Vitest unit test for a pure discount calculation function
import { describe, it, expect } from 'vitest';
import { calculateCartDiscount } from './discount.js';

describe('calculateCartDiscount', () => {
  it('applies a 10% discount above the threshold', () => {
    const result = calculateCartDiscount({ subtotal: 150, threshold: 100, rate: 0.10 });
    expect(result).toBe(135);
  });

  it('applies no discount below the threshold', () => {
    const result = calculateCartDiscount({ subtotal: 80, threshold: 100, rate: 0.10 });
    expect(result).toBe(80);
  });

  it('never returns a negative total for a 100% rate', () => {
    const result = calculateCartDiscount({ subtotal: 50, threshold: 0, rate: 1 });
    expect(result).toBe(0);
  });

  it('throws on a negative subtotal, no silent fallback', () => {
    expect(() => calculateCartDiscount({ subtotal: -10, threshold: 0, rate: 0.1 }))
      .toThrow('subtotal must not be negative');
  });
});

6. Integrationstests als Bindeglied

Integrationstests schließen die Lücke, die reine Unit-Tests zwangsläufig offenlassen: Sie prüfen, ob die Verträge zwischen realen Komponenten tatsächlich eingehalten werden. Ein typisches Beispiel ist ein API-Endpunkt, der mit Supertest gegen eine echte, isolierte Testdatenbank aufgerufen wird, um zu verifizieren, dass eine POST-Anfrage tatsächlich einen Datensatz anlegt und die richtige HTTP-Antwort liefert. Statt die Datenbank zu mocken, läuft hier ein echter PostgreSQL- oder MySQL-Container, oft über Testcontainers orchestriert, der vor jedem Testlauf in einen definierten Ausgangszustand zurückgesetzt wird. Genau diese Realitätsnähe macht Integrationstests wertvoll für Fehler, die reine Unit-Tests systematisch übersehen, etwa falsche SQL-Joins oder fehlende Datenbankindizes.

Für Frontend-lastige Architekturen eignet sich Playwright nicht nur für E2E-Tests, sondern auch für API-Integrationstests ohne Browser, bei denen direkt gegen REST- oder GraphQL-Endpunkte getestet wird, deutlich schneller als ein vollständiger UI-Durchlauf. Die Faustregel für die Abgrenzung zu Unit-Tests: Sobald ein Test einen Netzwerkaufruf, eine echte Datenbankverbindung oder einen Dateisystemzugriff benötigt, gehört er in die Integrationsebene, nicht in die Unit-Ebene. Contract-Tests mit Werkzeugen wie Pact ergänzen diese Ebene bei Microservice-Architekturen, indem sie prüfen, ob ein Consumer und ein Provider dieselbe API-Schnittstelle erwarten, ohne dass beide Services gleichzeitig laufen müssen.

// orders.integration.test.js - Supertest integration test against a real test database
import request from 'supertest';
import { app } from '../src/app.js';
import { resetTestDatabase } from './helpers/db.js';

describe('POST /api/orders', () => {
  beforeEach(async () => {
    await resetTestDatabase();
  });

  it('creates an order and persists it in the database', async () => {
    const response = await request(app)
      .post('/api/orders')
      .send({ productId: 'sku-42', quantity: 2 })
      .expect(201);

    expect(response.body).toMatchObject({
      status: 'pending',
      quantity: 2,
    });

    // Verify the row actually exists in the real test database
    const stored = await request(app).get(`/api/orders/${response.body.id}`).expect(200);
    expect(stored.body.productId).toBe('sku-42');
  });

  it('returns 422 when the product does not exist', async () => {
    await request(app)
      .post('/api/orders')
      .send({ productId: 'does-not-exist', quantity: 1 })
      .expect(422);
  });
});

7. E2E-Tests: Umfang und Grenzen

E2E-Tests sollten sich auf die kritischen Nutzerpfade beschränken, deren Ausfall unmittelbar Umsatz oder Kernfunktionalität gefährdet: Login, Produktsuche mit anschließendem Kauf, Checkout mit Zahlungsabwicklung, Registrierung. Cypress und Playwright bieten dafür eingebaute Wartemechanismen, die automatisch auf das Erscheinen von Elementen und den Abschluss von Netzwerkanfragen warten, statt mit festen Sleep-Zeiten zu arbeiten, was die häufigste Ursache für flackernde Tests in älteren Selenium-Suiten war. Playwright ergänzt das um Auto-Waiting auf Aktionierbarkeit von Elementen und eingebaute Trace-Viewer, die einen fehlgeschlagenen Testlauf Schritt für Schritt mit Screenshots und Netzwerklogs nachvollziehbar machen.

Die Grenzen von E2E-Tests liegen in ihrer Fragilität gegenüber Dingen, die nichts mit dem eigentlichen Fehler zu tun haben: Animationen, Drittanbieter-Skripte, Ladezeiten unter Last, Zeitzonenunterschiede zwischen CI-Runner und Anwendung. Jeder dieser Faktoren kann einen Test rot färben, ohne dass ein echter Bug vorliegt, und genau das untergräbt langfristig das Vertrauen des Teams in die gesamte Suite. Deshalb gilt für E2E-Tests eine strengere Regel als für die unteren Ebenen: nicht jede Funktionalität testen, sondern nur jeden kritischen Pfad einmal, und Randfälle, Fehlermeldungen sowie Validierungslogik konsequent auf Unit- und Integrationsebene abdecken, wo sie stabil und schnell prüfbar sind.

// checkout.cy.js - Cypress E2E test for the critical checkout path
describe('Checkout flow', () => {
  beforeEach(() => {
    cy.intercept('POST', '/api/orders').as('createOrder');
    cy.visit('/cart');
  });

  it('completes a purchase for a logged-in user', () => {
    cy.get('[data-testid="cart-item"]').should('have.length.at.least', 1);
    cy.get('[data-testid="checkout-button"]').click();

    cy.get('[data-testid="shipping-form"]').within(() => {
      cy.get('input[name="address"]').type('Main Street 1');
      cy.get('input[name="zip"]').type('12345');
      cy.get('button[type="submit"]').click();
    });

    cy.get('[data-testid="payment-method-invoice"]').click();
    cy.get('[data-testid="place-order-button"]').click();

    // Wait for the real network call instead of a fixed sleep
    cy.wait('@createOrder').its('response.statusCode').should('eq', 201);
    cy.get('[data-testid="order-confirmation"]').should('contain', 'Thank you');
  });
});

8. Die richtige Verteilung finden

Die oft zitierte 70/20/10-Verteilung, siebzig Prozent Unit-, zwanzig Prozent Integrations- und zehn Prozent E2E-Tests, ist ein brauchbarer Ausgangspunkt, aber keine feste Regel für jedes Projekt. Entscheidender als eine exakte Prozentzahl ist die Übung, eine bestehende Testsuite regelmäßig zu auditieren: Wie viele E2E-Tests prüfen eigentlich reine Geschäftslogik, die genauso gut, aber hundertmal schneller, als Unit-Test formuliert werden könnte? Wie viele Integrationstests ließen sich durch einen fokussierten Unit-Test mit einem sauberen Interface ersetzen? Diese Fragen decken systematisch auf, wo Tests unnötig weit oben in der Pyramide sitzen, nur weil es zum Zeitpunkt der Erstellung der einfachste Weg war.

In der CI-Pipeline lässt sich diese Verteilung durch gestufte Stages erzwingen, bei denen jede Stufe erst startet, wenn die vorherige besteht: Unit- und Integrationstests laufen bei jedem Push und liefern Feedback in wenigen Minuten, ein kleines E2E-Smoke-Set mit den wichtigsten Nutzerpfaden läuft vor jedem Deployment, eine größere E2E-Suite mit mehr Randfällen läuft nachts oder wöchentlich außerhalb des kritischen Pfads. Tags wie @critical oder @smoke in Cypress und Playwright ermöglichen es, gezielt eine Teilmenge auszuführen, ohne die gesamte Suite bei jedem Commit durchlaufen zu müssen.

# .github/workflows/test.yml - Run unit, integration, and E2E tests in staged jobs
name: Test Suite
on: [pull_request]

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx vitest run --coverage

  integration:
    needs: unit
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: test
        ports: ['5432:5432']
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run test:integration

  e2e-smoke:
    needs: integration
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test --grep "@critical"

9. Testpyramide im direkten Vergleich

Die folgende Übersicht fasst die wichtigsten Unterschiede zwischen den drei Ebenen zusammen und zeigt, warum die Form der Pyramide kein Dogma, sondern eine direkte Folge dieser Eigenschaften ist.

In der Praxis bestätigen Teams mit stabiler Pipeline diese Verteilung immer wieder: Sobald der Anteil der E2E-Tests über zehn bis fünfzehn Prozent steigt, wächst die durchschnittliche Pipeline-Laufzeit überproportional, während der Erkenntnisgewinn pro zusätzlichem Test sinkt, weil die kritischen Pfade bereits abgedeckt sind und neue E2E-Tests zunehmend Randfälle prüfen, die auf einer unteren Ebene günstiger und stabiler laufen würden.

10. Zusammenfassung

Die Testpyramide löst ein Kernproblem moderner Testautomatisierung: Vertrauen in eine Anwendung entsteht am günstigsten und schnellsten unten in der Pyramide, nicht oben. Unit-Tests mit Jest oder Vitest prüfen isolierte Logik in Millisekunden und liefern die höchste diagnostische Präzision. Integrationstests mit Supertest oder Playwright API-Tests verifizieren das Zusammenspiel realer Komponenten gegen echte Testdatenbanken. E2E-Tests mit Cypress oder Playwright sind unersetzbar für die Frage, ob ein echter Nutzer eine kritische Aufgabe erfolgreich abschließen kann, aber teuer, langsam und anfällig für Flakiness, wenn sie zur Hauptabsicherung statt zur gezielten Ergänzung werden.

Die richtige Verteilung ist kein starres Prozentschema, sondern das Ergebnis eines regelmäßigen Audits: Jeder E2E-Test, der eigentlich nur Geschäftslogik prüft, gehört nach unten verschoben. Eine gestufte CI-Pipeline mit klaren Zeitbudgets pro Ebene macht diese Kosten sichtbar und verhindert, dass die Testsuite langsamer wird als der Entwicklungsprozess, den sie eigentlich absichern soll.

11. FAQ: Die Testpyramide und E2E-Tests