Testautomatisierung im Browser

Was ist ein End-to-End-Test?

E2E-Test

Ein End-to-End-Test spielt einen vollständigen Anwendungsfall über die echte Benutzeroberfläche durch, so wie es eine Person tun würde. Er startet einen Browser, klickt, tippt und prüft am Ende das sichtbare Ergebnis, wobei Frontend, Schnittstellen und Datenbank gemeinsam beteiligt sind.

Wenn nach einem Release die Anmeldung klemmt, obwohl jeder einzelne Unit-Test grün war, fehlt genau die Prüfung, die den ganzen Weg einmal durchgeht.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Prüft: Den kompletten Weg über die Oberfläche
Werkzeuge: Playwright, Cypress, Selenium
Stabile Zugriffe: Rolle und Beschriftung, sonst ein Testattribut
Anteil: Wenige Tests für die wichtigsten Abläufe

Wie so ein Test abläuft

Werkzeuge wie Playwright oder Cypress steuern einen echten Browser. Der Test öffnet eine Seite, sucht Elemente, löst Aktionen aus und formuliert Erwartungen an das, was danach zu sehen ist. Weil dabei die gesamte Kette läuft, findet ein solcher Test Fehler, die kein Unit-Test sieht, etwa eine Schnittstelle, die nach dem Deployment eine andere Adresse hat, oder ein Formular, dessen Absendeknopf von einem Banner verdeckt wird.

Der Preis ist Zeit. Eine einzelne Prüfung dauert Sekunden statt Millisekunden, und mit jedem weiteren beteiligten System steigt die Zahl der Gründe, aus denen sie fehlschlagen kann. Deshalb decken End-to-End-Tests die wichtigen Wege durch die Anwendung ab, also Anmeldung, Bestellung, Bezahlung, und nicht jede Feldvalidierung.

Selektoren entscheiden über die Haltbarkeit

Wie du ein Element ansprichst, bestimmt, wie oft der Test später kaputtgeht. Selektoren, die sich an der CSS-Klassenstruktur oder am Pfad im Dokument entlanghangeln, brechen bei der nächsten Umgestaltung des Layouts, obwohl fachlich nichts anders ist.

Robuster sind Zugriffe über die sichtbare Rolle und die Beschriftung, also den Knopf mit der Aufschrift, die ein Mensch auch liest. Wo das nicht eindeutig geht, hilft ein eigenes Testattribut im Markup, das ausdrücklich für diesen Zweck vergeben wird und beim Umbauen mitgenommen wird.

Das Wackeln in den Griff bekommen

Der Ruf dieser Tests leidet fast immer an Durchläufen, die mal grün und mal rot sind. Die häufigste Ursache sind feste Wartezeiten im Test. Eine Sekunde reicht auf dem schnellen Entwicklungsrechner und nicht mehr auf dem ausgelasteten Runner. Moderne Werkzeuge warten stattdessen automatisch darauf, dass ein Element sichtbar und bedienbar ist, und genau darauf solltest du dich stützen statt auf Pausen.

Die zweite Ursache sind gemeinsam genutzte Testdaten. Läuft ein Test gegen dasselbe Konto wie ein anderer, hängt sein Ergebnis von der Reihenfolge ab. Jeder Test legt sich seine Daten deshalb selbst an oder bekommt einen eigenen Datensatz, damit die Reihenfolge egal ist.

Wenn ein Test im Durchlauf der Pipeline fehlschlägt, hilft die Aufzeichnung. Bildschirmfotos, Videomitschnitte und Ablaufprotokolle zeigen den Zustand im Moment des Fehlers, denn nachstellen lässt sich ein Fehlschlag auf dem Runner sonst kaum.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

End-to-End-Test und was oft damit gleichgesetzt wird

End-to-End-Test gegen Unit-Test

Ein Unit-Test prüft eine einzelne Einheit ohne Umgebung und läuft in Millisekunden. Der End-to-End-Test prüft das Zusammenspiel und braucht dafür die vollständige Anwendung.

End-to-End-Test gegen Integrationstest

Ein Integrationstest prüft das Zusammenspiel einiger Bausteine, etwa Anwendung und Datenbank, meist ohne Oberfläche. Der End-to-End-Test geht durch die Oberfläche.

End-to-End-Test gegen Abnahmetest

Der Abnahmetest beantwortet die fachliche Frage, ob das Gelieferte den Anforderungen entspricht. Er kann von Hand erfolgen, End-to-End-Tests sind eine mögliche technische Umsetzung davon.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Ein Test, dem niemand mehr glaubt, ist schlimmer als keiner

Sobald ein Durchlauf einmal rot und beim Wiederholen grün ist, gewöhnt sich das Team an, ihn einfach noch einmal zu starten. Von da an schützt die Suite nichts mehr. Die häufigste Ursache sind feste Wartezeiten, die auf einer schnellen Maschine reichen und auf dem ausgelasteten Buildserver nicht, statt einer Bedingung, auf die der Test wartet.

Tests, die sich an verschachtelten CSS-Klassen oder an der Position im Layout festhalten, brechen beim nächsten Umbau der Oberfläche. Am längsten halten Zugriffe über die Rolle eines Elements und seine sichtbare Beschriftung, weil sich beides nur ändert, wenn sich auch für die Anwender etwas ändert. Wo das nicht trägt, kostet ein eigenes Attribut, das ausschließlich für Tests existiert, einmal Abstimmung mit dem Frontend und hält danach jahrelang.

Der unterschätzte Teil sind die Daten. Ein Test, der ein Benutzerkonto anlegt und es nicht wieder entfernt, läuft beim zweiten Durchlauf in einen Namenskonflikt. Jeder Test sollte sich seinen Ausgangszustand selbst herstellen, sonst hängt das Ergebnis davon ab, in welcher Reihenfolge die Tests gelaufen sind.

End-to-End-Test lernen

Wie du stabile Selektoren wählst und Tests in die Pipeline hängst, üben die Trainings zu Playwright und Cypress an einer laufenden Anwendung.

Wenn die Tests danach bei jedem Push laufen sollen, findest du den passenden Rahmen in den Kurse zur Automatisierung mit GitHub Actions .

Kurse, die End-to-End-Test behandeln

Häufige Fragen

Wie viele End-to-End-Tests sind sinnvoll?

So wenige wie möglich und so viele wie nötig, um die geschäftskritischen Wege abzudecken. Alles, was sich eine Ebene tiefer prüfen lässt, gehört dorthin, weil es dort schneller läuft und die Ursache genauer benennt.

Playwright oder Cypress?

Beide lösen dieselbe Aufgabe zuverlässig. Playwright unterstützt mehrere Browser-Engines und mehrere Programmiersprachen, Cypress bindet sich enger an das JavaScript-Ökosystem und punktet mit seiner interaktiven Oberfläche beim Entwickeln. Entscheide anhand der Sprachkenntnisse im Team.

Gegen welche Umgebung soll getestet werden?

Gegen eine eigene Testumgebung mit kontrollierten Daten, nicht gegen die Produktion. Tests gegen echte Fremdsysteme werden unzuverlässig, sobald deren Verfügbarkeit schwankt, deshalb werden solche Zugriffe meist durch simulierte Antworten ersetzt.

Persönlich für dich da