Was ist ein End-to-End-Test?

Was „End to End“ hier bedeutet

Die beiden Enden sind der Mensch vor dem Bildschirm und das letzte System, das seine Eingabe verarbeitet. Ein End-to-End-Test lässt nichts dazwischen weg: Er startet die Anwendung so, wie sie ausgeliefert wird, bedient sie über ihre echte Oberfläche und prüft am Ende, was sichtbar herauskommt. Ob er „End to End“, „End-2-End“ oder „E2E“ heißt, ist nur eine Frage der Schreibweise, gemeint ist immer dasselbe.

Ein typischer Fall in einem Onlineshop: Der Test öffnet die Startseite, sucht einen Artikel, legt ihn in den Warenkorb, meldet sich an, schließt die Bestellung ab und prüft, ob die Bestätigung mit der richtigen Bestellnummer erscheint. Dabei laufen Frontend, API, Datenbank, Zahlungsanbindung (meist als Testsystem) und Mailversand gemeinsam. Bricht irgendwo in dieser Kette etwas, schlägt der Test fehl.

Weil die ganze Kette läuft, findet ein solcher Test Fehler, die kein Unit-Test sieht: eine Schnittstelle, die nach dem Deployment unter einer anderen Adresse liegt, ein Formular, dessen Absendeknopf von einem Cookie-Banner verdeckt wird, oder eine Konfiguration, die nur in der Testumgebung fehlt.

So sieht ein E2E-Test im Code aus

Werkzeuge wie Playwright oder Cypress steuern einen echten Browser. Der Test beschreibt Schritte und Erwartungen, das Werkzeug führt sie aus und wartet dabei selbstständig, bis ein Element sichtbar und bedienbar ist. Ein Anmeldetest mit Playwright in TypeScript sieht so aus:

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

test('Anmeldung mit gültigen Daten', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('E-Mail').fill('test@example.de');
  await page.getByLabel('Passwort').fill('geheim123');
  await page.getByRole('button', { name: 'Anmelden' }).click();
  await expect(page.getByRole('heading', { name: 'Willkommen' })).toBeVisible();
});

Auffällig ist, wie die Elemente angesprochen werden: über die Beschriftung und die Rolle, also so, wie ein Mensch sie auf dem Bildschirm erkennt. Selektoren, die sich an verschachtelten CSS-Klassen oder an der Position im Dokument entlanghangeln, brechen beim nächsten Umbau des Layouts, obwohl sich fachlich nichts geändert hat. Wo Rolle und Beschriftung nicht eindeutig sind, hilft ein eigenes Testattribut wie data-testid im Markup.

Der Platz in der Testpyramide

End-to-End-Tests stehen an der Spitze der Testpyramide. Das Bild beschreibt, wie sich die Tests einer Anwendung verteilen sollten: unten viele schnelle Tests für kleine Einheiten, darüber weniger Tests für das Zusammenspiel, oben wenige, aber aussagekräftige Tests für ganze Abläufe.

Der Grund für die Form ist der Preis. Jeder zusätzliche beteiligte Dienst ist ein weiterer Grund, aus dem ein Test fehlschlagen kann, und eine rote Meldung sagt dir nur, dass irgendwo in der Kette etwas klemmt, nicht wo. Deshalb decken End-to-End-Tests die geschäftskritischen Wege ab, also Anmeldung, Bestellung, Bezahlung, Registrierung, und nicht jede Feldvalidierung. Was sich eine Ebene tiefer prüfen lässt, gehört dorthin.

Gängige Werkzeuge

Die meisten Teams im Web arbeiten heute mit einem der folgenden Werkzeuge. Alle steuern einen echten Browser, sie unterscheiden sich in Sprache, Architektur und Bedienung.

• Playwright

  Von Microsoft, steuert Chromium, Firefox und WebKit und lässt sich mit TypeScript/JavaScript, Python, Java und .NET schreiben. Wartet automatisch auf Elemente und zeichnet auf Wunsch Traces mit Bildschirmfotos auf.

• Cypress

  Läuft eng am JavaScript-Ökosystem, Tests werden in JavaScript oder TypeScript geschrieben. Stark ist die interaktive Oberfläche, in der du jeden Schritt zurückverfolgen kannst.

• Selenium

  Der älteste Vertreter, baut auf dem W3C-Standard WebDriver auf und unterstützt viele Sprachen und Browser. Oft in großen, gewachsenen Testlandschaften im Einsatz.

• Robot Framework

  Ein Python-basiertes Rahmenwerk mit schlüsselwortgetriebener Syntax, das sich auch für Fachabteilungen lesen lässt. Für den Browser nutzt es Bibliotheken auf Basis von Selenium oder Playwright.

Ein End-to-End-Test braucht übrigens nicht zwingend einen Browser. Bei mobilen Apps übernimmt etwa Appium die Steuerung, bei reinen Backend-Systemen spielt der Test einen fachlichen Ablauf über mehrere Dienste hinweg nur über deren Schnittstellen durch. Entscheidend ist, dass der Ablauf von Anfang bis Ende reicht.