E2E-Tests einfach erklärt: ein Roboter testet deine Seite für dich

Was ein E2E-Test ist, einfach erklärt

Stell dir vor, du hast einen Schrank von IKEA zusammengebaut. Steht, Türen dran, schön. Aber bevor du dein Lieblingsgeschirr reinstellst - du rüttelst doch erst an jedem Brett und prüfst, ob die Schublade rausfällt, oder? Klar. Sonst kracht am dritten Tag das Brett mit dem Geschirr direkt auf die Katze.

Mit der Webseite ist es genauso. Du (genauer: dein Agent) hast eine Landingpage oder App gebaut. Sieht so aus, als würde sie laufen. Aber „sieht so aus“ ist keine Prüfung, sondern Hoffnung. Irgendwer muss die Seite wie ein echter Besucher öffnen, auf Buttons drücken, Formulare ausfüllen und sicherstellen, dass nichts abgefallen ist.

Dieser „Irgendwer“ kann ein geduldiger Mensch sein, der hundertmal dasselbe klickt und seinen Job still hasst. Oder es ist ein E2E-Test E2E (end-to-end, 'von Ende zu Ende') - ein Test, der den kompletten User-Weg prüft: vom Aufrufen der Seite bis zum Ergebnis, als säße ein echter Mensch am Rechner. - ein kleiner Roboter, dem du einmal erklärst, was zu tun ist, und der das danach tausendmal hintereinander makellos, gratis und ohne Burnout wiederholt.

Wozu ein Vibecoder E2E-Tests braucht

Du bist Vibecoder. Tests schreibst du nicht selbst von Hand. Aber wenn du verstehst, wozu sie gut sind und wie du den Agenten bittest, sie zu bauen, bekommst du gleich vier Dinge:

• du fängst Fehler ab, bevor der Kunde sie sieht - und nicht über eine wütende Nachricht um zwei Uhr nachts;
• du baust die Seite entspannt weiter: der Roboter sagt dir sofort, was genau du gerade kaputtgemacht hast;
• du sparst dir Stunden manueller Nachkontrolle nach dem Motto „läuft eigentlich noch alles?“;
• du wirkst wie ein Profi. Der Satz „ich habe Tests“ klingt selbst beim Auftraggeber souverän.

Ohne Tests ist jedes neue Feature ein Lottospiel. Eins repariert, heimlich was anderes kaputtgemacht, zufällig davon erfahren. Mit E2E-Tests hast du einen Wächter, der die ganze Seite in Sekunden abläuft.

Wie Claude E2E-Tests schreibt: ein Roboter in einem echten Browser

Das wichtigste Werkzeug hier ist Playwright Playwright - kostenloses Tool von Microsoft, das einen echten Browser (Chrome, Firefox, Safari) startet und ihn aus dem Code steuert: öffnet Seiten, klickt, tippt, prüft das Ergebnis. . Das sind die Hände und Augen des Roboters. Es öffnet einen echten Browser, geht auf deine Seite und verhält sich wie ein lebendiger User. Keine Simulation, keine Emulation - ein echter Chrome, gesteuert vom Code.

Ein Test ist ein User-Ablauf, kein Code

Ein guter E2E-Test liest sich fast wie eine Anleitung für die Oma: „geh auf die Seite, tipp ein Wort in die Suche, prüf, ob Ergebnisse auftauchen“. Du beschreibst den Weg eines Menschen, nicht das Innenleben des Codes. Genau das ist das ganze Geheimnis.

So sieht so ein Test aus. Von Hand schreiben musst du das nicht - das macht der Agent, aber es lohnt sich, ihn mal aus der Nähe zu sehen:

test('Suche findet Produkte', async ({ page }) => {
  await page.goto('/items')          // Seite geöffnet
  await searchInput.fill('Test')      // in die Suche getippt
  expect(count).toBeGreaterThan(0)    // geprüft: es wurde was gefunden
})

Laut vorgelesen - und klar, was passiert. So soll es sein.

Häng dich an data-testid, nicht an Text und Farbe

Der Roboter muss den Button auf der Seite irgendwie finden. Man kann sich an den Text hängen („Button mit der Aufschrift Kaufen“) - aber das ist fragil. Du änderst den Text in „Bestellen“, und der Test fällt aus dem Nichts um, obwohl die Seite einwandfrei läuft.

Deshalb hängen Profis den Elementen eine unsichtbare Markierung an - data-testid data-testid - ein spezielles unsichtbares Etikett an einem Seitenelement (zum Beispiel data-testid='kaufen'). Der User sieht es nicht, aber der Test findet darüber zuverlässig den richtigen Button, selbst wenn sich Text oder Farbe ändern. . Das ist wie ein Anhänger am Koffer. Den Koffer selbst kannst du knallpink umlackieren, aber der Anhänger mit der Nummer bleibt - und der Roboter findet immer das Richtige.

Warte auf ein Event, nicht einfach “warte mal”

Eine Seite lädt nicht sofort. Der Roboter rennt oft zum Button, bevor er da ist - und stolpert mit der Nase ins Leere. Der Anfänger-Reflex ist hier immer derselbe: „soll er halt 5 Sekunden warten“. Das ist die schlechteste Lösung überhaupt. Bei schnellem Internet hast du dem Test 5 Sekunden Leerlauf umsonst geschenkt. Und bei langsamem haben diese 5 Sekunden nicht gereicht, und der Test ist trotzdem umgefallen.

Wie macht man es richtig? Auf ein konkretes Event warten: „warte, bis die Daten geladen sind“, „warte, bis der Button sichtbar ist“. Der Roboter wartet genau so lange wie nötig, und keine Sekunde länger.

Guter E2E-Test gegen schlechter: wo der Unterschied liegt

Beispiel aus dem Leben: wie eine Animation die Bestellung kaputt machte

Du hast einen kleinen Onlineshop gebaut. Alles läuft. Eine Woche später hat der Agent auf deine Bitte eine schicke Animation auf den „Kaufen“-Button gepackt. Du hast dich gefreut, deployt und bist mit ruhigem Gewissen schlafen gegangen.

Morgens - eine Nachricht: „bei mir lässt sich die Bestellung nicht aufgeben“. Es stellte sich heraus: die Animation lag über dem Button, und er ließ sich physisch nicht mehr drücken. Du hast davon nichts mitbekommen. Warum? Weil du selbst die Bestellung nicht nachgeprüft hast - wozu auch, du hast ja nur die Animation angefasst.

Und jetzt stell dir dasselbe mit E2E-Tests vor. Nach der Änderung wäre der Roboter selbst den Weg „Produkt gewählt, Kaufen gedrückt, Formular ausgefüllt, Danke für die Bestellung gesehen“ gegangen, wäre am unsichtbaren Button gestolpert, hätte einen Screenshot gemacht und „KAPUTT“ gebrüllt - noch vor dem Deploy. Ohne versauten Morgen und ohne verlorenen Kunden.

Um so einen Roboter zu bekommen, musst du selbst nichts schreiben. Es reicht, den Agenten richtig zu bitten:

Schreib E2E-Tests mit Playwright für meine Seite. Deck die wichtigsten Abläufe eines echten Users ab:

Aufruf der Startseite und Prüfung, dass sie sich wirklich öffnet.
Komplette Bestellung: Produkt wählen, Kaufen drücken, Formular ausfüllen, Bestätigung sehen.
Suche auf der Seite: ein Wort eingeben und prüfen, dass Ergebnisse erscheinen.
Wichtige Regeln:

Häng dich an data-testid, nicht an Text oder Farbe. Wo es keine gibt - füg sie hinzu.
Verwende keine festen Pausen. Warte auf konkrete Events: das Laden der Daten, das Erscheinen eines Elements.
Mach bei einem Fehler einen Screenshot, damit man sieht, was kaputt ist.
Erklär mir einfach, wie ich diese Tests mit einem Befehl starte.

Wo es ohne E2E-Tests nicht geht und wo du locker bleiben kannst

Es gibt Stellen, wo ein Fehler nicht Nerven, sondern echtes Geld kostet. Dort sind Tests kein Luxus, sondern Pflicht. Und es gibt Zonen, wo du durchatmen und es nicht übertreiben kannst. Hier ist die Grenze:

Lass die Tests automatisch vor jedem Deploy laufen

Tests einmal schreiben - das ist zu wenig. Man vergisst sie verräterisch leicht. Deshalb sorgen Profis dafür, dass die Tests von selbst bei jedem Update der Seite laufen. Das nennt sich CI/CD - eine Pipeline für den Auto-Start. Der Roboter prüft alles vor der Veröffentlichung, und wenn auch nur irgendwas rot leuchtet, geht die Seite einfach nicht live, bis du es reparierst.

Das musst du nicht von Hand einrichten. Bitte den Agenten: „richte den Auto-Start der E2E-Tests vor jedem Deploy ein“. Fertig. So werden die Tests aus „irgendwann prüf ich das mal“ zu einer dauerhaften Absicherung, die nicht schläft.

Häufige Anfängerfehler bei E2E-Tests

• Gar keine Tests schreiben. „Hab ich doch geprüft“ funktioniert genau bis zur ersten Änderung, die heimlich alles kaputtmacht.
• Den Code testen statt den User. Der Test soll den Weg eines echten Menschen gehen, nicht im Innenleben wühlen.
• Sich an Text und Farbe hängen. Aufschrift geändert - Test umgefallen. Nimm data-testid.
• “Warte 5 Sekunden”-Pausen reinstopfen. Das ist der direkte Weg zu Flaky-Tests, denen keiner glaubt.
• Einen umgefallenen Test ignorieren. Ein roter Test ist ein Signal, kein Hindernis. Reparieren, nicht abschalten „damit er nicht stört“.
• Geld-Tests auf der Live-Seite laufen lassen. Tests mit Bezahlung - nur auf einer Testkopie.