Playwright: Zuverlässige Browser-Tests von Microsoft für alle Browser

Was ist Playwright?

Playwright ist ein Open-Source-Framework für Browser-Automatisierung und End-to-End-Tests, das von Microsoft entwickelt wird. Es wurde 2020 veröffentlicht und hat sich schnell zu einem der beliebtesten Werkzeuge im Bereich Browser-Testing entwickelt. Das Projekt entstand aus den Erfahrungen des Teams hinter Puppeteer und geht in vielen Aspekten deutlich über dessen Möglichkeiten hinaus.

Was Playwright besonders auszeichnet: Es unterstützt alle drei großen Browser-Engines – Chromium (Chrome, Edge), Firefox und WebKit (Safari) – mit einer einheitlichen API. Dadurch lassen sich Tests schreiben, die auf allen relevanten Browsern identisch ausgeführt werden, ohne dass der Testcode angepasst werden muss.

Multi-Browser-Unterstützung im Detail

Playwright bringt eigene, angepasste Browser-Builds mit, die über npx playwright install heruntergeladen werden. Das bedeutet, man ist unabhängig von den lokal installierten Browser-Versionen – ein großer Vorteil in CI-Umgebungen, wo konsistente Browser-Versionen oft schwer sicherzustellen sind.

Mit einem einzigen Konfigurationseintrag lässt sich festlegen, dass alle Tests in allen drei Browsern ausgeführt werden sollen. In der Datei playwright.config.ts definiert man dazu ein projects-Array mit den gewünschten Browsern. Playwright führt die Tests dann automatisch für jede Konfiguration aus und aggregiert die Ergebnisse in einem gemeinsamen Bericht.

Auto-Waits: Keine flaky Tests mehr

Eines der häufigsten Probleme bei Browser-Tests sind sogenannte flaky Tests – Tests, die sporadisch fehlschlagen, weil Elemente noch nicht geladen sind oder Animationen noch laufen. Playwright begegnet diesem Problem mit einem durchdachten Auto-Wait-Mechanismus.

Bevor Playwright mit einem Element interagiert – etwa klicken, tippen oder einen Screenshot machen –, prüft es automatisch eine Reihe von Voraussetzungen: Ist das Element im DOM? Ist es sichtbar? Ist es nicht deaktiviert? Ist keine Animation im Gange? Erst wenn alle Bedingungen erfüllt sind, wird die Aktion ausgeführt. Diese Prüfungen laufen intern in einer Retry-Schleife, bis ein konfigurierbares Timeout überschritten wird.

page.locator(): Moderne Element-Selektion

Playwright verwendet page.locator() als zentrales Konzept für die Element-Selektion. Im Gegensatz zu direkten Element-Handles ist ein Locator lazy – er evaluiert den Selektor erst bei der tatsächlichen Interaktion. Das macht Locators widerstandsfähig gegen DOM-Änderungen zwischen zwei Anweisungen.

Playwright empfiehlt semantische Selektoren: page.getByRole('button', { name: 'Absenden' }) findet einen Button anhand seiner ARIA-Rolle und seines zugänglichen Namens. Weitere hilfreiche Methoden sind page.getByLabel(), page.getByPlaceholder() und page.getByTestId(). Diese Ansätze fördern gleichzeitig die Barrierefreiheit, da Tests auf korrekte ARIA-Attribute angewiesen sind.

Praxis-Tipp: Nutze page.getByRole() als primären Selektor. Diese Methode spiegelt wider, wie Nutzerinnen und Nutzer – sowie Screenreader – eine Seite wahrnehmen. Tests, die auf ARIA-Rollen basieren, dokumentieren gleichzeitig die semantische Korrektheit der Anwendung und sind deutlich stabiler als CSS-Selektor-basierte Tests.

Screenshots und Videos bei Fehlern

Playwright kann beim Auftreten eines Testfehlers automatisch einen Screenshot speichern. In der Konfigurationsdatei reicht screenshot: 'only-on-failure', um dieses Verhalten zu aktivieren. Ähnliches gilt für Videoaufzeichnungen: Mit video: 'retain-on-failure' wird ein Video des Testablaufs nur dann gespeichert, wenn der Test fehlschlägt.

Diese Artefakte landen standardmäßig im test-results/-Verzeichnis und können in CI-Systemen als Build-Artefakte archiviert werden. Das macht die Fehleranalyse im Team erheblich einfacher, ohne dass jemand den Test lokal reproduzieren muss.

Codegen: Tests automatisch aufzeichnen

Playwright bietet mit dem Codegen-Tool eine einzigartige Möglichkeit, Tests durch einfaches Bedienen der Anwendung zu generieren. Der Befehl npx playwright codegen https://meine-app.de öffnet einen Browser mit einem aufgezeichneten Code-Panel daneben. Jede Nutzeraktion – Klicks, Eingaben, Navigationen – wird sofort in Playwright-Testcode umgewandelt.

Der generierte Code ist ein guter Ausgangspunkt, der anschließend manuell verfeinert werden sollte. Codegen wählt dabei automatisch die semantisch sinnvollsten Locator-Strategien – bevorzugt getByRole() und getByLabel(). Das spart bei der Testentwicklung erheblich Zeit, besonders für komplexe Formulare und Wizard-Abläufe.

Parallele Testausführung ohne Zusatzkosten

Im Gegensatz zu Cypress, das für parallele Ausführung die kostenpflichtige Cloud-Lösung empfiehlt, bietet Playwright parallele Tests als kostenloses eingebautes Feature. Standardmäßig werden Testdateien parallel über mehrere Worker-Prozesse verteilt. Die Anzahl der Worker lässt sich über workers in der Konfigurationsdatei steuern.

Playwright verwendet Isolation auf Worker-Ebene: Jeder Worker erhält seinen eigenen Browser-Kontext. Tests innerhalb einer Datei laufen sequenziell, aber verschiedene Dateien laufen parallel. Mit der Option fullyParallel: true werden auch Tests innerhalb einer Datei parallelisiert.

Der Trace Viewer

Der Playwright Trace Viewer ist ein mächtiges Debugging-Werkzeug. Mit trace: 'on' zeichnet Playwright während des Tests eine vollständige Aufzeichnung auf, die DOM-Snapshots, Netzwerkanfragen, Konsolenausgaben und Screenshots für jeden Testschritt enthält.

Die gespeicherte Trace-Datei lässt sich mit npx playwright show-trace trace.zip lokal öffnen – oder direkt im Online-Tool unter trace.playwright.dev. Man kann zum exakten Zeitpunkt eines Fehlers zurückspulen und den DOM-Zustand, die Konsolenausgaben und den aktiven Selektor auf einen Blick sehen.

Achtung: Traces erzeugen erhebliche Mengen an Daten und verlangsamen die Testausführung spürbar. Verwende in der CI-Konfiguration daher trace: 'retain-on-failure', um Traces nur bei fehlgeschlagenen Tests zu speichern. Das Aufzeichnen von Traces für alle Tests in einem großen Projekt kann zu langen Ausführungszeiten und viel Speicherverbrauch führen.

Playwright Test vs. Cypress: Vergleich

Kriterium Playwright Cypress
Browser-Unterstützung Chromium, Firefox, WebKit/Safari Chromium, Firefox (kein Safari)
Parallele Tests Kostenlos eingebaut Kostenpflichtig (Cypress Cloud)
Programmiersprachen JS/TS, Python, Java, C# Nur JavaScript/TypeScript
Interaktive UI UI-Modus (neu), Trace Viewer Test Runner (sehr ausgereift)
Codegenerierung Ja (Codegen-Tool) Nein
Multi-Tab / iframes Vollständig unterstützt Eingeschränkt
Component Testing Experimentell Stabil (seit v10)
Einstiegshürde Niedrig Niedrig
TypeScript-First Ja, natives TypeScript Unterstützt, aber nicht primär

FAQ zu Playwright

Muss ich Playwright oder Cypress wählen – oder kann ich beides nutzen?
Beides kann in einem Projekt koexistieren, was aber selten sinnvoll ist. Playwright ist die bessere Wahl, wenn man Safari-Unterstützung, Multi-Tab-Tests, mehrsprachige Teams (Python/Java) oder kostenlose Parallelisierung benötigt. Cypress punktet mit einem ausgereifteren interaktiven Test Runner und stabilem Component Testing. Für neue Projekte empfehlen viele Teams heute Playwright.
Was ist der Unterschied zwischen page.locator() und page.$$()?
page.locator() gibt einen Locator-Objekt zurück, der lazy ist und Auto-Waits besitzt. page.$$() ist ein direkter DOM-Query, der sofort ausgeführt wird und kein automatisches Warten unterstützt. Für Produktionstests sollte man immer Locators verwenden und $$-Methoden meiden.
Kann Playwright mit bestehenden Selenium-Tests zusammenarbeiten?
Nein, Playwright und Selenium verwenden völlig unterschiedliche Protokolle und APIs. Es gibt keine direkte Kompatibilität. Für eine Migration müssen Selenium-Tests manuell oder mit Hilfe des Codegen-Tools neu geschrieben werden. Das Codegen-Tool beschleunigt diesen Prozess erheblich.
Wie teste ich Authentifizierungsabläufe effizient?
Playwright unterstützt das Speichern des Authentifizierungsstatus (Cookies, Local Storage) mit page.context().storageState(). Einmal eingeloggt, kann der gespeicherte Zustand in allen Folgetests wiederverwendet werden, ohne dass der Login-Vorgang wiederholt wird. Das spart erheblich Zeit in Test-Suites mit vielen Tests, die Authentifizierung voraussetzen.