Menü
schließen
Auf dem Markt für End-to-End-Tests (E2E) gibt es eine Vielzahl von Tools, insbesondere im kommerziellen Bereich. Da wir bei Aclue Open Source Technologien bevorzugen, fallen diese in den meisten Fällen weg. Obwohl sie oft viele zusätzliche Funktionen bieten, sind diese für die Sicherstellung der Softwarequalität in der Regel nicht unbedingt erforderlich.
Zu den Vertretern im Open Source-Bereich gehören unter anderem Cypress, TestCafe, Webdriver.io, Puppeteer, Selenium WebDriver und Playwright. Einige von ihnen bieten auch kommerzielle Cloud-Varianten an.
Playwright wird von Microsoft entwickelt – dem Unternehmen, das uns TypeScript gebracht hat. Es hat eine große Fangemeinde auf GitHub; Mit über 56.000 Sternen und über 3.000 Forks ist es eines der beliebtesten Open-Source-Projekte für E2E-Tests.
Playwright führt Tests durch und steuert den Browser von außen über die API und teilt den Ausführungskontext nicht mit der Anwendung – ähnlich wie bei Cypress, Protractor oder Selenium.
Da Playwright-Tests außerhalb des Browsers ausgeführt werden, habt ihr eine größere Auswahl an Sprachen, in denen ihr eure Tests schreiben könnt: Ihr seid nicht nur auf JS oder seine Varianten wie bei Protractor, Cypress oder Nightwatch.js beschränkt. Derzeit könnt ihr eure Tests in folgenden Sprachen schreiben:
Dies bietet euch die Flexibilität, die Tests an das Projekt anzupassen und die Sprache auszuwählen, um die vorhandenen Fähigkeiten in Ihrem Team optimal zu nutzen.
Mit Playwright könnt ihr eure Tests in den gängigsten Browsern ausführen:
Die Headless-Ausführung wird für alle Browser auf allen Plattformen unterstützt.
Der Funktionsumfang von Playwright deckt alles ab, was für umfangreiche E2E-Tests benötigt wird. Ihr könnt Tests mit einem Testgenerator aufzeichnen, Auto-Waiting bei vielen Aktionen verwenden und beliebige Assertions setzen.
Besonders interessant sind weitere Funktionen wie der Vergleich von Screenshots mit einer bestimmten erlaubten Pixelabweichung, das Debuggen der Tests innerhalb des Browsers und ein Trace Viewer, mit dem ausgeführte Tests genau nachvollzogen werden können.
Für Benutzeroberflächen, die direkt APIs im Browser verwenden, z.B. um den Batteriestatus auf dem Smartphone abzurufen, bietet Playwright auch die Möglichkeit, Browser-APIs zu mocken und zu überprüfen. Außerdem können API-Aufrufe mit Mocks versehen werden. Es ist auch möglich, LocalStorage-Werte zu setzen und zu überprüfen.
In der EU gibt es immer mehr gesetzliche Vorgaben dafür, dass im öffentlichen Sektor auf Barrierefreiheit geachtet werden muss bzw. bestimmte Bedingungen nach WCAG erfüllt sein müssen. Viele Tests innerhalb dieses Standards lassen sich nicht unbedingt automatisch testen. Diejenigen, die jedoch möglich sind, können mit Playwright automatisiert durchgeführt werden.
Es ist immer hilfreich, wenn in der Automatisierungskette auch ein entsprechender Webserver gestartet werden kann. Zum Beispiel habe ich einen SpringBoot-Service für meine Testausführung angebunden, der im Testmodus läuft und entsprechende Mock-Informationen bereitstellt.
Eine SpringBoot-Anwendung im Testmodus (spring-boot:test-run) hat den Vorteil, dass die Anwendung um zusätzliche API-Endpunkte erweitert werden kann, um spezielle Testdaten/-szenarien vorzubereiten, bevor der E2E-Test bestimmte Tests ausführt. Damit innerhalb der Tests ein solcher Endpunkt angesprochen werden kann, bietet Playwright auch die Möglichkeit, in der Testdefinition Aufrufe abzusetzen.
Ein Problem bei E2E-Tests ist oft der Umgang mit Benutzerauthentifizierungen. Aber auch hier stellt Playwright entsprechende Funktionen bereit, um allgemein verschiedene Benutzer für Testgruppen oder einzelne Tests zu verwenden.
Neben klassischen E2E-Tests für eine Webseite können mit Playwright auch einzelne Komponenten getestet werden. Diese Funktion ist noch experimentell. Ich habe selbst noch keine Erfahrungen damit gemacht und bin gespannt, wie gut es bereits funktioniert.
Playwright bietet weitere Funktionen zur Testausführung. Neben der Auswahl verschiedener Browser gibt es die Möglichkeit einer Emulation mit bestimmten Viewports, Locales, Zeitzonen, Berechtigungen, Geolocations und Offline-Schaltungen. Für die Testausführung können eine Vielzahl von definierten Geräten verwendet werden.
Dies verschärft jedoch das generelle Problem von E2E-Tests mit der teilweise langen Ausführungszeit. Um dieses Problem zu lösen, besteht die Möglichkeit, Tests parallel auszuführen. Je mehr CPU-Kerne auf dem Rechner vorhanden sind, desto mehr Worker können für die Parallele Ausführung verwendet werden.
Genügt dieses nicht, so kann über Sharding die Last bzw. Testfälle auf mehrere Maschinen verteilt
werden. Das schöne dabei, wer in Github Actions unterwegs ist, kann es auch dort durch eine simple Konfiguration verwenden.
Die Dokumentation von Playwright ist äußerst umfassend und hilfreich. Und das Beste ist, dass es tatsächlich genauso funktioniert, wie es dort beschrieben wird. Wie oft kommt es vor, dass die Beschreibung in der Dokumentation nicht passt oder nicht funktioniert?
Der Funktionsumfang ist beeindruckend und deckt praktisch alles ab, was sich ein Entwickler oder Tester wünschen kann. Es gibt auch verschiedene Erweiterungen wie zum Beispiel Lighthouse für Playwright, falls man den Google Analyzer für Web-Apps automatisiert ausführen möchte.
Auch eine Testabdeckung kann für den im Browser vorhandenen JavaScript-Code und CSS-Anweisungen ermittelt werden. Allerdings ist diese Funktion derzeit noch recht umständlich zu verwenden.
In den letzten 10 Jahren habe ich viele Tools für E2E-Tests verwendet. Der Funktionsumfang ist sicherlich bei vielen Tools gestiegen, insbesondere weil viele Funktionen erst in den letzten Jahren von den Browsern unterstützt werden. Aber ich bin bisher sehr begeistert von Playwright. Besonders unter dem Gesichtspunkt, dass bestimmte Features nicht nur in einer kostenpflichtigen Version verfügbar sind, sondern frei zugänglich sind.
