UI-Tests von Hand zu schreiben kostet Zeit: Man muss die passenden Locator finden, Assertions formulieren und – sobald es um das Aussehen der Anwendung geht – auch noch Screenshot-Vergleiche aufsetzen.
Playwright bringt dafür bereits sehr mächtige Bordmittel mit, allen voran das eingebaute Visual Testing. Kombiniert man das Ganze zusätzlich mit KI-Unterstützung, lassen sich Selektoren und Testfälle deutlich schneller ableiten – und man bekommt sogar Hilfe bei der Interpretation von Screenshot-Diffs.
In diesem Beitrag zeige ich anhand eines einfachen Formulars mit zwei Radio-Buttons – live auf meiner eigenen Website im Testlab – wie man mit Playwright visuelle Tests aufsetzt, und wie KI dabei an mehreren Stellen unterstützen kann.
Also, viel Spaß! 🙂
Worum geht es in diesem Beitrag?
Wir gehen hier folgende Schritte durch:
Kurzer Überblick: Was ist Visual Testing in Playwright überhaupt?
Ein Testszenario mit einem Formular (Radio-Buttons) auswählen.
KI nutzen, um daraus einen passenden Locator und Testfall abzuleiten.
Mit Playwrights eingebautem Visual Testing (toHaveScreenshot) einen Screenshot-Vergleich aufsetzen.
Die Sensitivität des Vergleichs über maxDiffPixels steuern.
KI nutzen, um Diff-Ergebnisse und sinnvolle Schwellenwerte einzuschätzen.
Was ist Visual Testing in Playwright?
Neben funktionalen Assertions (Texte, Attribute, Zustände) bietet Playwright mit Visual Comparisons eine eingebaute Möglichkeit, das tatsächliche Erscheinungsbild einer Seite oder Komponente zu überprüfen.
Das Prinzip dahinter ist simpel:
Beim ersten Testlauf erstellt Playwright automatisch einen Referenz-Screenshot (Baseline) und legt ihn im Projekt ab.
Bei jedem weiteren Lauf wird ein neuer Screenshot erstellt und pixelweise mit der Baseline verglichen.
Weichen die Bilder zu stark voneinander ab, schlägt der Test fehl – inklusive Diff-Bild, das genau zeigt, wo sich etwas geändert hat.
Der zentrale Befehl dafür ist expect(locator).toHaveScreenshot() – wahlweise für die komplette Seite oder, wie in diesem Beispiel, für einen einzelnen Locator. Damit eignet sich Visual Testing besonders gut, um unbeabsichtigte Layout- oder Styling-Änderungen aufzudecken, die reine Text- oder Attribut-Assertions gar nicht erst bemerken würden – etwa ein verschobener Button, eine falsche Farbe oder ein Radio-Button, der optisch nicht mehr wie ausgewählt aussieht, obwohl sein value-Attribut technisch stimmt.
Damit das Ganze nicht nur graue Theorie bleibt, habe ich das Beispielformular direkt in mein eigenes Testlab auf Softwaretests.org (Abschnitt 3) eingebaut. Dort findet sich jetzt eine Card-Komponente mit zwei Radio-Buttons – Option 1 und Option 2:
Ziel des Tests: Sobald Option 1 ausgewählt ist, soll ein visueller Vergleich sicherstellen, dass sich am Erscheinungsbild des Formulars nichts unbeabsichtigt ändert. Wer mitmachen möchte, kann sich die Karte direkt live im Testlab ansehen und die folgenden Schritte 1:1 nachvollziehen.
Zunächst wird ein Locator für genau diesen Formularbereich definiert – nicht für die gesamte Seite. Das hat den Vorteil, dass der Screenshot-Vergleich sich ausschließlich auf den relevanten Ausschnitt bezieht und nicht durch Änderungen an anderer Stelle der Seite gestört wird.
Locator mit KI-Unterstützung ableiten
Genau wie sich mit KI Selektoren aus echtem HTML-Markup für andere Anwendungsfälle ableiten lassen, funktioniert das auch hier. Man kopiert den relevanten HTML-Ausschnitt der Card in den Chat und lässt sich einen robusten Locator vorschlagen.
Ein Prompt dafür könnte sein:
Hier ist ein Ausschnitt aus meiner Formular-Karte:
<div class="nb-card">
<form id="visual-test-form">
<input type="radio" name="options" id="option1" value="option1" /> Option 1
<input type="radio" name="options" id="option2" value="option2" /> Option 2
</form>
</div>
Erstelle einen Playwright-Locator, der die gesamte Karte auswählt,
sowie separate Locator für die beiden Radio-Buttons.
Ich nutze dafür Claude.ai und erhalte daraufhin fertige Locator-Vorschläge, inklusive einer kurzen Begründung, warum sie stabil sind (z. B. Verwendung von Rollen statt CSS-Klassen):
Testfall inkl. Visual Assertion generieren lassen
Auf Basis der Locator kann man die KI direkt bitten, den kompletten Testfall zu erzeugen – inklusive Auswahl des Radio-Buttons und der visuellen Prüfung:
Erstelle einen Playwright-Test in JavaScript, der:
1. Zu https://softwaretests.org/testlab/ navigiert
2. Innerhalb der Formular-Karte (#visual-test-form) den Radio-Button "Option 1" auswählt
3. Per expect(...).toHaveScreenshot() einen visuellen Vergleich
nur für die Formular-Karte durchführt
Das Ergebnis ist ein Test, der den gewünschten Locator nutzt und await expect(formLocator).toHaveScreenshot() aufruft.
Wichtig: Beim allerersten Lauf existiert noch kein Referenzbild – der Test schlägt daher zunächst erwartungsgemäß fehl:
..und Playwright legt automatisch einen Baseline-Screenshot im Testordner ab:
Der zweite Run ist wie zu erwarten sofort erfolgreich, denn der aktuelle Zustand entspricht der Baseline.
Screenshots vergleichen
Ändere ich den Test nun so, dass statt Option 1 die Option 2 ausgewählt wird, und führe ihn erneut aus, vergleicht Playwright den aktuellen Zustand erneut mit der zuvor gespeicherten Baseline.
Da sich das Formular sichtbar unterscheidet, schlägt der Test diesmal mit der Fehlermeldung Expect locator to have screenshot fehl.
Die Differenz lässt sich zwar auch direkt im test-results-Ordner als Bilddatei (Actual, Expected, Diff) einsehen, deutlich komfortabler ist aber der Playwright HTML-Reporter: Dort gibt es einen eigenen Bereich für die visuelle Validierung mit mehreren Ansichten:
Diff: zeigt Actual und Expected gegenübergestellt an.
Side-by-side: beide Screenshots nebeneinander.
Slider: besonders praktisch bei kleinen, schwer erkennbaren Unterschieden – man schiebt einen Regler über das Bild und sieht den Übergang zwischen altem und neuem Zustand.
In unserem Beispiel ist der Unterschied offensichtlich: Option 1 ist im Referenzbild ausgewählt, Option 2 im aktuellen Lauf.
Sensitivität mit maxDiffPixels steuern
Der Reporter zeigt außerdem an, wie viele Pixel sich unterscheiden – in meinem Testlab-Beispiel waren es 323 Pixel (0,02 % aller Pixel des Kartenausschnitts), nachdem statt Option 1 nun Option 2 ausgewählt wurde.
Kleinere Layout-Schwankungen zwischen einzelnen Testläufen sind zwar grundsätzlich nicht ungewöhnlich, in diesem Fall ist die Abweichung aber tatsächlich beabsichtigt: Der Radio-Button-Zustand hat sich sichtbar geändert.
Für Fälle, in denen man solche Abweichungen bis zu einem gewissen Grad tolerieren möchte, lässt sich eine Toleranzschwelle definieren:
Mit einem Schwellenwert von 350 Pixeln liegt unsere Abweichung von 323 Pixeln darunter, der Test wird also trotz der optischen Änderung als bestanden gewertet.
Senkt man den Wert auf z. B. 200, schlägt der Test wieder fehl, weil die 323 Pixel Unterschied nun über der Toleranz liegen.
Alternativ lässt sich die Toleranz auch relativ zur Bildgröße angeben, was oft robuster ist, wenn sich die Abmessungen der Komponente später einmal ändern:
Dieselbe Einstellung lässt sich übrigens auch zentral in der playwright.config.js hinterlegen, sodass sie für alle toHaveScreenshot-Aufrufe im Projekt als Standard gilt:
Optional: KI zur Einschätzung von Diffs und Schwellenwerten nutzen
Neben der Generierung von Locatoren und Testcode kann KI auch bei der Bewertung von Screenshot-Differenzen helfen. Beschreibt man der KI die Art der Änderung (z. B. “220 Pixel Unterschied durch geänderten Radio-Button-Zustand” oder fügt einen Ausschnitt des Diff-Bildes bei), lässt sich gezielt einschätzen:
Ob es sich vermutlich um eine echte, relevante UI-Änderung handelt oder um ein Rendering-Rauschen.
Welcher maxDiffPixels-Wert für eine bestimmte Komponente sinnvoll wäre.
Ob eine Komponente eher pixelbasiert (toHaveScreenshot) oder besser über einzelne Assertions (Text, Attribute) getestet werden sollte.
Ein Beispiel-Prompt:
Mein Playwright-Visual-Test zeigt eine Abweichung von 220 Pixeln
zwischen Baseline und aktuellem Screenshot. Die einzige bewusste
Änderung war die Auswahl eines anderen Radio-Buttons. Ist ein
maxDiffPixels-Wert von 200 für diese Komponente sinnvoll, oder
würde das echte visuelle Regressionen verschlucken?
So wird KI nicht nur zum Schreiben von Code genutzt, sondern auch als Sparringspartner bei Testdesign-Entscheidungen.
Schauen wir also, was wir als Antwort erhalten:
In Ordnung, ergibt Sinn. 🙂
Baseline aktualisieren
Ändert sich das Layout der Anwendung bewusst, müssen die Referenzbilder aktualisiert werden. Das geht projektweit mit einem einzigen Befehl:
npx playwright test --update-snapshots
Playwright führt daraufhin alle Tests in allen konfigurierten Browsern aus und legt jeweils neue Baseline-Screenshots an.
Tipps für bessere Ergebnisse
1. Locator statt ganzer Seite testen: Ein Screenshot-Vergleich auf Komponentenebene (z. B. nur die Formular-Karte) ist stabiler und aussagekräftiger als ein Full-Page-Screenshot.
2. maxDiffPixels bewusst wählen: Zu niedrig führt zu False Positives durch minimale Rendering-Schwankungen, zu hoch verschluckt echte Regressionen. KI kann hier eine erste Einschätzung liefern, die letzte Entscheidung bleibt aber beim Team.
3. Cross-Browser einplanen: Wenn die Konsistenz über mehrere Browser hinweg wichtig ist, gehören eigene Baseline-Bilder pro Browser dazu. Ich plane hierzu in Zukunft separate Tutorials.
4. KI-Vorschläge immer gegenprüfen: Sowohl generierte Locator als auch Einschätzungen zu Diffs sollten kurz manuell verifiziert werden, bevor sie fest im Test landen.
5. Update-Snapshots bewusst einsetzen:--update-snapshots überschreibt alle Referenzbilder – das sollte nur nach bewussten, gewollten UI-Änderungen erfolgen, nicht routinemäßig.
Fazit: Visual Testing wird mit KI noch zugänglicher
Playwrights eingebautes Visual Testing ist bereits für sich genommen ein mächtiges, kostenloses Werkzeug für UI-Regressionstests.
Kombiniert man es mit KI-Unterstützung – beim Ableiten von Locatoren, beim Generieren der Testfälle und sogar bei der Einschätzung von Screenshot-Diffs – lässt sich der gesamte Prozess spürbar beschleunigen, ohne an Kontrolle über die Tests zu verlieren.
Und: Das Beispielformular ist wie gesagt im Testlab verfügbar, wer möchte kann die Schritte also direkt selbst nachbauen. 🙂
