E2E-Testing mit Playwright: Der Weg der Mitte

Inhaltsverzeichnis

Playwright ist mit Baujahr 2020 ein relativ junges, von Microsoft entwickeltes Framework für End-to-End-Testing (E2E), das das dominierende Framework Cypress mit neuen Features herausfordert. Wir geben Leserinnen und Lesern anhand konkreter Codebeispiele einen tieferen Einblick in Playwright und wie sich damit Tests schreiben lassen.

Beim Testen von Webanwendungen gibt es neben den herkömmlichen Testmethoden wie Unit-Tests mittels Testing-Frameworks wie Jest oder Vitest die Möglichkeit, einen Browser fernzusteuern und damit die Anwendung fast wie ein Endbenutzer zu bedienen. Dadurch lassen sich Fehler entdecken, die unter Umständen bei isolierten Tests nicht auftreten würden. Derzeit dominiert Cypress die Landschaft der End-2-End-Testing-Frameworks, aber Playwright hat dieses Jahr an Fahrt aufgenommen und kann durchaus als "Shooting Star" 2022 bezeichnet werden.

Cypress zeichnet sich vor allem durch die Stabilität der Tests und die Developer Experience aus, die ein einfaches und schnelles Schreiben von Tests erlaubt. Da Cypress und Selenium die beiden vorherrschenden E2E-Testing-Technologien sind, wird Playwright im weiteren Verlauf an verschiedenen Stellen in Bezug zu ihnen gesetzt.

E2E-Testing-Frameworks im Vergleich

Um Befehle in einem Browser auszuführen, muss jedes E2E-Testing-Framework einen Browser hochfahren und steuern können. An diesem Punkt sind bereits Entscheidungen zu treffen, die einen enormen Einfluss haben. Zum Beispiel lässt Cypress den Test direkt im Browser laufen – also neben der Anwendung, die es zu testen gilt. Dadurch hat der Testcode direkten Zugriff auf das DOM (Document Object Model). Das heißt, wenn ein Cypress-Test auf einen Button klickt, ist das ein JavaScript-Befehl auf das DOM-Element. Bei einem außerhalb des Browsers laufenden Test wäre eine Abstraktionsschicht zur entsprechenden Synchronisierung zwischen Test und Browser nötig.

Der In-Browser-Ansatz hat aber auch Schwachstellen. Zum Beispiel ist ein Klick auf ein Element kein realer Klick, da die click()-Methode des DOM-Objekts ausgeführt wird. Solche minimalen Unterschiede sind bereits Grund genug, dass beispielsweise Google Cypress nicht verwendet. Da der Testcode in JavaScript läuft, gelten dieselben Regeln wie für jeden anderen Code auch. Er kann nur auf der Domäne laufen, von der er geladen wurde. Ein Hin- und Herspringen zwischen Domänen ist nur über Workarounds realisierbar.

Auf der anderen Seite der E2E-Skala steht Selenium beziehungsweise die Familie der WebDriver-basierten Frameworks. Hier laufen die Tests außerhalb der Browser unter Verwendung von WebDriver, der für die Übersetzung zuständig ist. WebDriver ist ein W3C-Standard (World Wide Web Consortium). Es gibt eine Reihe weiterer Frameworks neben Selenium, die diesen Ansatz nutzen, darunter WebDriver.io und Nightwatch. Im Vergleich zu Cypress haben sie den Ruf, für "Flakiness" (Unzuverlässigkeit) anfällig zu sein. WebDriver stammt aus einer Zeit, bevor es Single-Page-Anwendungen (SPA) gab und als jede Benutzeraktion ein erneutes Laden der Seite bewirkte. Single-Page-Anwendungen erfordern einen wesentlich höheren Grad an Kommunikation, dem das aktuelle WebDriver-Protokoll nicht gerecht wird.

Mit WebDriver-basierten Frameworks durchgeführte Tests sind allerdings nicht an Same-Origin-Einschränkungen gebunden und können damit deutlich mehr Kontrolle über den Browser ausüben. Die verschiedenen WebDriver sorgen für "Cross-Browser-Unterstützung" und DOM-Aktionen wie ein Klicken sind ein realer statt eines JavaScript-Befehls.

Cypress ist bezüglich der Browserunterstützung limitiert auf die Familie der Chromium-Browser (Chrome, Edge, Chromium), Mozilla Firefox und WebKit (Engine für Safari und seit Version 10.8 experimentell). Im Alltag stellt sich die Frage, inwiefern die Cross-Browser-Unterstützung durch WebDriver für das eigene Projekt relevant ist – bei einer Marktabdeckung von über 70 Prozent durch Chromium-Browser und mit dem Hintergrund, dass ein Großteil der Fehler, die auf einem Smartphone-Browser auftreten, auch in einem Desktop-betriebenen auftauchen würden. Es ist aber auf jeden Fall ein Argument, das man abwägen sollte.

Zusammengefasst glänzen WebDriver-basierte E2E-Frameworks wie Selenium mit Cross-Browser-Unterstützung und bieten mehr Kontrolle über den Browser. Allerdings sind Einbußen hinsichtlich der Verlässlichkeit hinzunehmen. Bei Cypress gilt im Grunde genommen die gegenteilige Situation, wobei hier vor allem die ausgezeichnete Developer Experience hervorzuheben ist.

Playwright versucht, einen Mittelweg zu gehen: Es unterstützt – wie Cypress – alle Chromium-basierten Browser wie Chrome, Edge und Opera. Ferner gibt es eine Unterstützung für Mozilla Firefox, WebKit (Apple Safari) und experimentell für Android. Die Tests werden wie bei WebDriver außerhalb der Browser ausgeführt, allerdings mit einer Verlässlichkeit, die der von Cypress entspricht. Auch in Bezug auf die Developer Experience hat Playwright einiges zu bieten und mit dem Trace Viewer überragt es in manchen Bereichen sogar Cypress. Man muss allerdings festhalten, dass es an die Developer Experience von Cypress (noch) nicht herankommt.

Die Architektur von Playwright

Chromium-basierte Browser steuert Playwright über das Chrome DevTools Protocol (CDP). Es bietet eine umfassende Unterstützung zur Fernsteuerung und wird beispielsweise auch für die DevTools verwendet. Wer sich schon intensiv mit den DevTools auseinandergesetzt hat, dürfte deren Möglichkeiten kennen und schätzen. Google Chrome, Microsoft Edge und Opera basieren alle auf dem Open-Source-Browser-Chromium, den auch Playwright verwendet. Zudem unterstützt Playwright auch Firefox und WebKit. Obwohl Firefox CDP anbietet, verwendet Playwright eine eigens geschriebene Anbindung. In Zukunft soll Playwright jedoch auch Firefox nativ über CDP ansprechen können.

Bleibt noch die Unterstützung für Safari. Da Safari in Windows nur als veraltete Version und auf Linux offiziell gar nicht verfügbar ist, bettet das Playwright-Team die WebKit-Engine in einen minimalen, selbstgeschriebenen Browser ein und liefert diesen mit Playwright aus.

Das könnte die Frage aufwerfen, wie ein Team, das ein E2E-Framework entwickelt, nebenbei einen eigenen Minibrowser schreibt, zumal andere Firmen ganze Abteilungen damit beschäftigen. Überschätzt sich das Playwright-Team hier etwas? Das tut es nicht, denn Playwright ist von ehemaligen Chrome-Entwicklerinnen und -Entwicklern erstellt worden, die von Google zu Microsoft abwanderten. Das heißt, das Kernteam hat zuvor bei Google an den DevTools und Puppeteer gearbeitet. Puppeteer ist die von Google bereitgestellte Bibliothek, um CDP in Node.js verwenden zu können. Überspitzt formuliert, lässt sich Playwright durchaus als Nachfolger von Puppeteer bezeichnen. Selbst Cypress greift für seine WebKit-Unterstützung auf den "Playwright WebKit Browser" zurück.