UI-Testing bezeichnet den Ansatz, eine Web-Anwendung als Ganzes aus Nutzerperspektive zu testen, indem Backend-Requests durch vordefinierte Mock-Responses ersetzt werden. Das Frontend läuft dabei isoliert im Browser, ohne echte Datenbank oder Backend. So lassen sich Abläufe schnell, stabil und parallel prüfen, ohne den Aufwand vollständiger End-to-End-Tests.
Das Wichtigste in Kürze
- UI-Tests mit gemockten API-Responses ersetzen bei Felix Wunderlichs Team sowohl Komponententests als auch die meisten End-to-End-Tests und liefern 280 Tests in unter drei Minuten auf einer 16-Gigabyte-VM.
- Wer das Frontend gegen definierte Mock-Responses isoliert testet, prüft die gesamte Anwendung aus Nutzerperspektive, ohne Backend, Datenbank oder Testdatenmanagement hochfahren zu müssen.
- Playwright erlaubt es, HTTP-Requests im Browser-Kontext abzufangen und sofort mit vorbereiteten Antworten zu ersetzen, was parallele Testläufe und browserübergreifende Prüfungen in unterschiedlichen Viewport-Größen ermöglicht.
- Das größte Setup-Risiko liegt nicht im Testkonzept selbst, sondern in fehlender Zentralisierung: CSS-Selektoren, Request-Definitionen und Response-Fixtures müssen von Anfang an an einem Ort gesammelt werden, sonst zieht jede kleine UI-Änderung Dutzende Testanpassungen nach sich.
Komponententests und End-to-End-Tests reichen für Frontends nicht aus
Wer ein Frontend testet, sitzt oft zwischen zwei Welten, die beide nicht passen. Auf der einen Seite die Komponententests: isoliert, klein, meist als Unit-Test gebaut. Auf der anderen Seite die End-to-End-Tests: vollständig, aber langsam und teuer im Aufbau. Dazwischen klafft eine Lücke, in die genau das fällt, was eigentlich zählt: die Anwendung so, wie ein Nutzer sie bedient.
Komponententests hängen eine Einzelkomponente per Jest, Mocha oder einem ähnlichen Werkzeug in einen kleinen DOM und prüfen sie für sich. Manchmal kommen Verbund-Tests dazu, die eine ganze Form abdecken. Das Problem zeigt sich beim Umbau der UI. Sobald eine Komponente verschoben oder neu zusammengesteckt wird, gehen reihenweise Tests kaputt, die niemand anfassen wollte.
End-to-End-Tests haben das umgekehrte Problem. Sie laufen gegen eine dockerisierte Umgebung mit eigener Datenbank und eigenem Testdatenmanagement. Das ist aufwendig. Einzelne UI-Teile oder Fehlerfälle dort abzudecken, lohnt sich wirtschaftlich nicht. Und wenn nach zehn Minuten Laufzeit der letzte Schritt scheitert, beginnt das Spiel von vorn.
Das Frontend als ganze Anwendung isoliert testen
Der Ansatz, der die Lücke schließt, testet das Frontend als vollständige Applikation aus Nutzerperspektive, ohne das echte Backend hochzufahren. Die Anwendung läuft in einem Browser-Kontext, wie ihn Playwright, Cypress oder Test Café bereitstellen. In diesem Kontext lassen sich die Requests abfangen, die sonst an Backends, APIs oder Datenbanken gehen.
Statt das echte System zu starten, ersetzt der Test die Antworten durch vordefinierte Mock-Responses. Das Frontend glaubt, es spreche mit dem echten System, läuft aber komplett gekapselt. Damit testet man die ganze Anwendung als Nutzer, nicht nur Bruchstücke davon.
Felix Wunderlich hat diesen Weg bei Volkswagen im Software Development Center in Wolfsburg eingeführt, wo sein Team Software für Werkstätten baut. Die technische Umsetzung mit Playwright ist überschaubar: Im Test definiert man für eine Route, dass sie auf einen bestimmten Request eine bestimmte Mock-Response zurückgibt. Mehr braucht es für ein funktionierendes Frontend zunächst nicht.
Wenn ich mein Frontend als echte Applikation aus Nutzerperspektive isoliert teste, das Ganze auch noch parallel und schnell, dann habe ich im Prinzip alle Gewinne, die ich mir vorstellen kann.
Felix Wunderlich
Warum die ganze Bedienkette durchlaufen ein Vorteil ist, kein Umweg
Der Test bedient die Anwendung so, wie ein Nutzer es tun würde, inklusive aller Schritte davor. Bei einem Widget mit fünf Steps füllt der Test tatsächlich alle fünf aus, auch wenn er nur die Form im letzten Step prüfen will. Auf den ersten Blick wirkt das unintuitiv, fast verschwenderisch.
Der Gewinn liegt im Zustand der Anwendung. Wer den Wizard von Schritt zu Schritt durchläuft, stellt sicher, dass der interne Applikationszustand des Frontends über die ganze Kette valide bleibt. Genau das ersparrt die Bastelei mit künstlich gesetzten Zwischenzuständen und den dazugehörigen Mocks.
Validierungen, unterschiedliche Ergebnisse, abgehende Requests im letzten Schritt: all das lässt sich verskripten und einzeln durchtesten. Das Vorgehen ist überraschend schnell, weil die Schritte davor nicht der teure Teil sind.
UI-Tests müssen nicht langsam und instabil sein
Langsamkeit und Flakiness gelten als die Standardeinwände gegen UI-Tests. Beide schmelzen mit gemockten Responses deutlich. Weil keine echten Backends antworten, lassen sich viele Tests parallel laufen.
Die Zahlen aus der Praxis: 280 UI-Tests laufen in unter drei Minuten auf einer virtuellen Maschine mit 16 Gigabyte in der Pipeline. Für diese Menge ist das schnell.
Bei der Stabilität gewinnt der Ansatz sogar dazu. Die Tests laufen über verschiedene Browser und in verschiedenen Größen. So fällt ein Bug auf, der sich in einer bestimmten Firefox-Version zeigt, schon im Test auf, nicht erst in der Produktion. Was sonst spät und zufällig auffällt, wird explizit.
Was der Ansatz für die Qualität bringt
Der Hauptgewinn ist Sicherheit bei jeder Änderung. Nach jedem noch so kleinen Change steht fest, dass die UI als Ganzes aus Nutzerperspektive weiter funktioniert. Man kann die Codequalität des Frontends verbessern, am Ende alle Tests laufen lassen und sich auf das grüne Ergebnis verlassen.
Das war mit Einzelkomponententests nicht möglich. Dort lief im Zweifel zehn Minuten der E2E-Test, der letzte Schritt scheiterte, und alles begann von vorn. Der Wechsel hat diese Schleife abgeschafft.
Konsequenterweise gibt es im Team keine Komponententests mehr. Bei der Migration wurden alle End-to-End-Tests, die nicht für den User-Flow oder das Gesamtsystem relevant waren, herausgezogen und in UI-Tests überführt.
Vergleich: drei Testarten für das Frontend
| Testart | Umfang | Geschwindigkeit | Schwachstelle |
|---|---|---|---|
| Komponententest | einzelne Komponente im DOM | schnell | bricht beim UI-Umbau, isoliert vom echten Ablauf |
| End-to-End-Test | ganzes System mit Backend und DB | langsam | aufwendiges Setup, unwirtschaftlich für Detailfälle |
| UI-Test mit Mock-Responses | ganze Anwendung, Backend gemockt | schnell, parallelisierbar | Setup-Aufwand am Anfang, Duplizierung bei geteilten Komponenten |
Wo der Ansatz wehtut: Duplizierung und Setup
Zwei Stellen haben sich als unangenehm herausgestellt. Die erste ist Duplizierung bei geteilten Komponenten. Ein Button mit asynchroner Operation, Loading-Spinner und grünem Haken kann an drei Stellen im Userflow auftauchen. Dann gibt es an drei Stellen einen Test, der dasselbe prüft.
Das widerspricht dem Wunsch, nichts doppelt zu schreiben. In einem komplizierteren Fall ließ sich das auflösen, indem die Komponenten auseinandergezogen wurden. Trotzdem bleibt die berechtigte Frage im Team, ob derselbe Test wirklich dreimal nötig ist.
Die zweite Stelle ist die Pflege des Setups. Als sich ein CSS-Selektor änderte, mussten Dutzende Tests angepasst werden. Daraus folgte eine klare Lehre für den Aufbau.
So baust du das Setup, damit Änderungen nicht durchschlagen
Bevor du startest, schau dir deine UI genau an und schreib auf, womit sie im Hintergrund kommuniziert. Dieser Überblick ist die Grundlage für alles Weitere.
Sammle danach zentral, was sich sonst über die Tests verstreut:
- die CSS-Selektoren der UI-Elemente an einer Stelle
- die Requests an einer Stelle
- wiederverwendbare Response-Bilder und Test-Datenbilder als Bausteine
Dieses zentrale Setup ist am Anfang viel Arbeit und nicht die schönste. Der Nutzen zeigt sich danach. Ändert sich eine Backend-API und schickt eine andere Response, passt du das Response-Bild an einer Stelle an. Solange die Änderung die UI nicht betrifft, läuft alles weiter wie vorher.
Für ein bestehendes Produkt mit vorhandenen Komponenten- und End-to-End-Tests ist der Setup-Aufwand zu Beginn hart. Er lohnt sich trotzdem deutlich.
Ein Experiment schlägt eine Grundsatzdebatte
Die Idee setzte sich durch, weil sie als Experiment startete, nicht als Vorgabe. Der Schmerz war täglich spürbar, jeder im Team hatte ihn. Die Migration von zu vielen End-to-End-Tests hin zu UI-Tests war vom Aufwand her überschaubar. Also wurde es ausprobiert.
Ein Experiment darf scheitern. Geht es schief, bleibt man beim alten Schmerz oder sucht eine andere Lösung. Hier ging es auf, und genau dieser geglückte Versuch hat die volle Akzeptanz im Team geschaffen.
Geholfen hat das Umfeld. Im Software Development Center besitzen die Teams ihre Produkte selbst und versuchen, das Beste zu bauen. Wer Neues ausprobieren will, findet dafür Raum.
Was als Nächstes ansteht
Mehr Tests bedeuten irgendwann mehr Laufzeit. Bei 500 UI-Tests über mehrere Jahre Produktentwicklung werden auch diese langsamer. Einfach eine größere Maschine in die Pipeline zu werfen, ist für einen Ingenieur keine befriedigende Antwort: Du wirfst Geld auf das Problem, statt es zu lösen.
Die naheliegende Richtung ist Sharding, also die Tests aufzuteilen und die Parallelisierung weiter hochzutreiben. Wie weit sich das ausreizen lässt, ist noch offen, aber Spielraum ist da.
Der größere Hebel liegt in der Verbreitung. Der Ansatz soll in weiteren Produkten zum Einsatz kommen, und langfristig könnte UI-Testing über mehrere Werkzeuge hinweg akzeptiert sein. Viele Kollegen gehen mit der Idee mit, hängen aber an ihren bevorzugten Werkzeugen. Wenn das Konzept werkzeugunabhängig akzeptiert wird, könnte es zum neuen Standardweg werden, eine UI zu testen.
