End-to-End-Test (E2E-Test)

Ein End-to-End-Test (E2E-Test) prüft das System so, wie ein Nutzer es verwendet, mit lauter echten Schichten: Browser, Frontend, Backend-Services, Datenbank, Queues und, wo praktikabel, Integrationen von Drittanbietern. Er beantwortet die Frage, die tiefere Teststufen nicht beantworten können: Funktioniert das Ganze bei einer echten Journey tatsächlich zusammen? E2E-Tests stehen an der Spitze der Testpyramide, weil sie die realistischste Sicherheit zu den höchsten Kosten liefern.

Beispiel (Playwright)

import { test, expect } from '@playwright/test';

test('guest can buy a product', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('searchbox', { name: 'Search' }).fill('desk lamp');
  await page.keyboard.press('Enter');
  await page.getByRole('link', { name: 'Desk Lamp' }).click();
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.getByRole('link', { name: 'Checkout' }).click();
  await page.getByLabel('Email').fill('guest@example.com');
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByRole('heading', { name: 'Thank you for your order' })).toBeVisible();
});

Ein einziger Test durchläuft Suche, Katalog, Warenkorb, Checkout und Bestellservice. Serialisiert der Warenkorb-Service Preise falsch, fängt dieser Test das ab, selbst wenn die Unit-Tests jedes Service bestehen.

Warum man nur wenige davon hat

• Langsam. Sekunden bis Minuten pro Test, gegenüber Millisekunden bei Unit-Tests.
• Anfällig für Flakiness. Mehr bewegliche Teile bedeuten mehr Timing-Probleme, geteilte Daten und instabile Umgebungen.
• Schlechte Diagnose. „Checkout fehlgeschlagen“ kann an jedem von einem Dutzend Services liegen.
• Teuer in der Wartung. UI-Änderungen ziehen sich durch viele Tests.

Reservieren Sie E2E-Tests deshalb für geschäftskritische Journeys wie Registrierung, Kauf und Kernabläufe, und decken Sie Varianten (jede Validierungsregel, jede Rabattart) auf Unit- und API-Ebene ab.

So werden sie zuverlässig

• Verwenden Sie bedingungsbasiertes Warten wie das Auto-Waiting und die Web-First-Assertions von Playwright oder WebDriverWait in Selenium, niemals feste Sleeps.
• Legen Sie Testdaten über APIs an, im Setup statt per Klick durch die UI, und geben Sie jedem Test seine eigenen Daten.
• Verwenden Sie stabile Locators: Rollen, Labels und Test-IDs statt layoutabhängigem XPath.
• Strukturieren Sie den Code mit Page Objects oder Ähnlichem, damit eine UI-Änderung an einer Stelle behoben wird.

„End-to-End“ und „Systemtest“ überschneiden sich: Der Systemtest ist die Teststufe, E2E beschreibt die Art von Test, die durch alle Schichten geht.