Running, Debugging und Analyse

Obwohl die Realisierung von Playwright [1] primär auf der JavaScript-Laufzeitumgebung Node.js basiert, wie es der erste Teil dieser Artikelserie [2] beschrieben hat, bezieht das Framework für das Testen und die Automatisierung browserbasierter Apps auch andere Technologien, Frameworks und Programmiersprachen mit ein. So hat Microsoft neben den Java­Script/TypeScript-APIs über Node.js auch Schnittstellen für Java, .NET/C# [3] und Python implementiert. Zusätzlich hat das Team bei Microsoft die gängigen Unit-Testing-Frameworks (JUnit [4], MSTest [5]/NUnit [6] und pytest [7]) in Playwright integriert.Alle Schnittstellen ermöglichen eine durchgehende Programmierung indi­vidueller Testfälle für browserbasierte Apps mit den zuvor genannten Sprachen und den damit verbundenen Konventionen. Das in Playwright realisierte Tooling führt vorhandene Tests aus und hilft, Fehler mittels Debugging in der Implementierung der Tests zu suchen und erhaltene Testergebnisse zu analysieren. Damit bietet Playwright für browserbasierte Apps ein breites Leistungsspektrum für alle Tätigkeiten im konkreten Entwicklungszyklus und für den gesamten Software-Lifecycle an.

Ausführung von Playwright-Tests erfolgt abhängig vom Projekttyp

Es empfiehlt sich generell, die Testfälle der browserbasierten App mit der jeweils im Entwicklungsprojekt verwendeten Sprache zu programmieren. Die Ausführung der implementierten Testfälle sollte auch auf Basis der für die eingesetzte Programmiersprache zugrunde liegenden Softwaretechnologie erfolgen.Diese Vorgehensweise erleichtert die Realisierung der Testfälle, da ein Programmierer keine weitere Sprache erlernen muss. Zudem bleiben die Infrastrukturen für Entwicklung und Test identisch, sodass sich kein zusätzlicher Aufwand für Dev­Ops durch eine weitere, neue Technologiekomponente eigens für den Test ergibt.Für das in der .NET-Welt im Projekt eingesetzte Unit-Testing-Framework erzeugt der Terminalbefehl dotnet new [mstest | nunit] -n <testordner> in einem bestehenden Projekt ­einen Testordner mit allen Unit-Test-Ressourcen. Anschließend installiert der Befehl dotnet add package Microsoft.Playwright.[MSTest | NUnit] alle notwendigen Playwright-Abhängigkeiten in das Projekt. Die Eingabe von dotnet test -h zeigt alle verfügbaren Optionen für die Testausführung sowie eine kurze Erläuterung an.Dabei nimmt das Argument --filter <Expression> abhängig vom jeweils eingesetzten Unit-Testing-Framework (MSTest, NUnit, xUnit) verschiedene Bezeichnungen für den mit Expression verbundenen Ausdruck ein. Eine Liste aller im Projekt verfügbaren Tests gibt der Befehl dotnet test --list-tests aus. Grundsätzlich führt in der .NET-Welt der CLI-Befehl dotnet test alle programmierten Testfälle aus. Um einen bestimmten Test auszuführen, greift man auf den Befehl dotnet test --filter “TestClassName“ zurück.Für die Programmierung mit JavaScript/TypeScript installiert der Befehl npm init playwright@latest das Testing-Framework Playwright in das Projekt. Angelehnt an die Konventionen der TypeScript-Welt befindet sich die Konfigura­tion der Playwright-Tests standardmäßig in der Datei playwright.config.ts. Das über Node.js verfügbare Command-Line-Tool npx führt Playwright-Tests mittels npx playwright test aus. In der Node.js-Welt hat Microsoft für VS Code einen eigenen Test Runner mit speziellen Features für End-to-End-Tests realisiert: Playwright Test for VSCode. Nach Installa­tion dieser Marketplace-Extension erscheint im Quellcode-Editor bei jedem Testfall ein neues Kontextmenü (Bild 1).

Ein Python-Projekt benötigt eine virtuelle Python-Umgebung, eine Installation von Playwright (pip install playwright) und des pytest-Plug-ins für Playwright [8]: pip install pytest-playwright. Für die Ausführung von Playwright-Tests hat Microsoft das pytest-CLI um eigene Argumente und zusätzliche pytest-Fixtures erweitert. Eine pytest.ini-Datei reicht alle darin enthaltenen Argumente direkt an das CLI weiter. Übergibt man pytest einen in Python implementierten Testfall, so kommt dieser zur Ausführung. Mehrere Testfälle parallelisiert das pytest-Plug-in pytest-xdist [9]. Dabei legt dessen Argument --numprocesses die Anzahl parallel auszuführender Testfälle fest; diese ist auf das Maximum vorhandener CPUs beschränkt.Die Programmierung von Playwright-Tests mit Java basiert auf Maven [10]. Im Java-Maven-Projekt zeigt der Terminalbefehl mvn -v[ersion] unter anderem die Versionsnummer und das Home-Verzeichnis des angezogenen Maven-Systems an. Die Installation von Playwright führt der Maven-Befehl mvn exec:java -e -D exec.mainClass=com.microsoft.playwright.CLI -D exec.args=”install” durch. Zuvor muss für Playwright-Tests der dependency-Eintrag in der Project-Object-Model-Datei (POM) von Maven erweitert werden (Listing 1). In Java programmierte Playwright-Tests führt der JUnit-Test-Runner aus. Die Konfiguration einer parallelen Ausführung erfolgt über den maven-surefire-plugin-Eintrag in der POM-Datei.

BrowserContexts und Page-Objekte bieten ­Unabhängigkeit für Testfälle

Einer vollständigen Isolierung der Testfälle voneinander kommt bei ihrer Ausführung eine besondere Bedeutung zu: Mögliche externe Abhängigkeiten der Testfälle und -daten dürfen nicht zu Folgeproblemen führen. Jeder Testfall muss unabhängig von allen anderen ausführbar sein. Nur dann verfügt jeder Testfall über einen eigenen Zuständigkeits­bereich, der in sich abgeschlossen ist und keine externen Abhängigkeiten aufweist.Diese Voraussetzungen stellen sicher, dass auftretende Fehler ursächlich nicht aus bereits vorhandenen Fehlern resultieren. Damit bildet eine vollständige Isolierung die Basis, um enthaltene Fehler schneller sowie einfacher zu finden und direkt im Quellcode der App zu beheben. Zudem gewährleistet eine Isolierung der Testfälle, dass jede Ausführung eines Testfalls immer dasselbe Ergebnis liefert, was eine automa­tische Auswertung aller Testergebnisse erleichtert.Playwright implementiert eine derartige Isolierung der Testfälle mittels eines Browser-Kontexts; dieser gewährleistet, mehrere Browser-Sessions unabhängig voneinander ­ausführen zu können. Sobald das Playwright-Modul eine Browser-Instanz startet, erzeugt diese mittels der New­ContextAsync()-Methode ein Browser-Kontext-Objekt (Listing 2); in der Playwright-Terminologie BrowserContext genannt. Zu ­jedem Browser-Kontext-Objekt gehört standardmäßig ein Page-Objekt, das die Methode NewPageAsync() zugänglich macht.

Das Page-Objekt verfügt über Methoden, um mit einem Tab (einer Seite) des Browsers zu kommunizieren und bestimmte Aktionen durchzuführen. Sobald ein bestimmter Browser-Kontext nicht mehr benötigt wird, gibt ein Aufruf der CloseAsync()-Methode diesen und alle dazugehörigen Ressourcen frei. Grundsätzlich stellt Playwright sicher, dass jedes von beziehungsweise in einer Browser-Session initiierte oder instanzierte Objekt zum selben Browser-Kontext gehört und diesem zugänglich ist.Auch innerhalb einer Browser-Session kann Playwright weitere voneinander unabhängige Sessions starten. Dazu genügt es, über die jeweilige Browser-Session einfach ein ­neues Browser-Kontext-Objekt zu erzeugen. Jedes neue, innerhalb der Browser-Session instanzierte Browser-Kontext-Objekt verfügt über eine eigene, isolierte Ausführungsumgebung und erlaubt es dennoch, mit jedem der anderen Browser-Kontexte wie auch mit deren Page-Objekten zu kommunizieren.

Auto-Wait hilfreich für deterministische

Testausführung

Eine einfache fixe Wartezeit, also ein zeitlich fixer Hard-Wait, lässt sich jederzeit auch mit Playwright realisieren (Bild 2). Im Unterschied zu anderen Testing-Frameworks oder -Libraries verfügt Playwright über ein Auto-Wait-Feature, um Flaky-Tests möglichst auszuschließen (siehe Kasten Vermeidung von Flaky-Tests). Dieses ­Auto-Wait-Feature von Playwright zielt darauf ab, die Verfügbarkeit von Elementen sicherzustellen, bevor das Framework eine bestimmte Aktion durchführt.

Jedes Auto-Wait wartet, bis alle mit dem Element verknüpften Prüfungen erfolgreich sind, und bringt erst danach die verlangte Aktion zur Ausführung.Das Auto-Wait-Feature gewährleistet, dass die anschließend mit dem jeweiligen Element durchzuführenden Aktionen sich entsprechend der Intention des Tests verhalten. Sollten die mit dem Element verbundenen Prüfungen nicht innerhalb eines bestimmten Time-outs ausführbar sein, bricht der Testfall die Aktion mit einem Time­outError ab.Playwright teilt die seitens des Auto-Wait-Features für ein bestimmtes Element durchzuführenden Prüfungen in verschiedene Statuszustände ein:Attached: Ein mit dem DOM (Document Object Model) oder ShadowRoot verbundenes Element gilt als Attached. Dabei übernimmt die isConnected-Property die Prüfung auf Verknüpfung mit dem DOM.Visible: Ein Element gilt als Visible, wenn es keine leere Bounding-Box ist und die CSS-visibility nicht auf hidden steht. Als nicht Visible gelten alle Elemente mit einer CSS-size von zero oder einem CSS-display von none.Stable: Behält ein Element eine und dieselbe Bounding-Box für mindestens zwei aufeinanderfolgende Animations-Frames bei, so gilt es als Stable.Receives Events: Befindet sich das Ziel eines Klicks am Aktionspunkt des Elements, so besitzt dieses den Zustand Receives Events.Enabled: Das Element wird als Enabled betrachtet, es sei denn, es handelt sich um eines der Elemente <button>, <select>, <input> oder <textarea> mit einer disabled-Property.Editable: Ein Element gilt als Editable, wenn es Enabled ist und es keine readonly-Property besitzt.Die genannten Prüfungen für ein Element finden abhängig von der mit ihm durchzuführenden Aktion statt. So findet die Aktion getAttribute nur für ein Element mit dem Zustand/Status Attached statt. Zudem besitzen einige der mit einem Element durchzuführenden Aktionen wie zum Beispiel ClickAsync() für .NET eine force-Option.Erhält diese force-Option den Wert true, so finden alle mit dieser Aktion verbundenen Auto-Wait-Prüfungen nicht statt, das heißt, sie entfallen und die gewünschte Aktion wird sofort ausgelöst. Damit lässt sich ein Element testen, das sich ­eigentlich in einem nicht erreichbaren oder verfügbaren Zustand befindet (nicht sichtbar/verdeckt, deaktiviert).

Locator stellt die Schaltzentrale für die ­Ausführung von Playwright-Tests dar

Unter einem Locator versteht man ein Hilfsmittel (Konstrukt), um innerhalb einer laufenden Browser-orientierten App ein bestimmtes Element zu finden. Ein Locator dient als Ausgangsbasis für die Ausführung der mit ihm verbundenen ­Auto-Waits.Mithilfe des in Playwright integrierten Code-Generators (auch Playwright Inspector genannt) ermittelt der Programmierer den zum jeweiligen Locator gehörenden Quellcode (siehe [2]). Playwright enthält eine Reihe vordefinierter Built-in Locators, die innerhalb einer Webseite über das Page-Objekt das gewünschte Element zugänglich machen. Anschließend stellt der Locator alle mit dem zugehörigen DOM-Element verbundenen Aktionen bereit.Aufgrund der Hierarchie der Elemente des DOM lassen sich mehrere Locators iterativ verketten, um ein bestimmtes Zielelement zu erreichen. Änderungen im Quellcode einer App können unter Umständen bewirken, dass die Methode eines Built-in Locators nicht mehr das gewünschte Element der Webseite ermittelt. Um derartige Situationen nahezu auszuschließen, empfiehlt sich der Einsatz des Built-in Locators Page.GetByTestId(). Dabei erfolgt der Zugriff auf das Element der Webseite über das zugehörige data-testid-Attribut. Ein Aufruf der Methode playwright.Selectors.SetTestIdAttribu­te(”data-pw”) definiert ein data-testid mit dem in ”” übergebenen Namen.Anschließend steht im HTML-Code der App data-pw als ­eigenständiges Attribut zur Verfügung, dessen Wert der Programmierer entsprechend setzen kann. Greift ein Testfall über diesen Wert xxx mittels page.GetByTestId(”xxx”) auf den Locator zu, so bleibt dieser Wert selbst bei Änderungen bezüglich der Features der App unverändert. Damit gewährleistet der Einsatz eines TestID-Locators eine wesentlich höhere Stabilität für den Quellcode der mit Playwright programmierten Testfälle.Grundsätzlich funktionieren alle Locators von Playwright auch mit den Elementen des Shadow-DOM. In manchen Situationen gelingt der Zugriff auf einen Locator nur mittels ­eines CSS- oder XPath-Selektors. Jedoch sollte der Programmierer im Testfall deren Einsatz auf ganz wenige Sonderfälle beschränken, da diese sich im DOM öfters ändern können.

Mittels Assertions die korrekte Ausführung ­eines Testfalls prüfen

Assertions (Zusicherungen, Sicherstellungen) dienen in vielen Programmiersprachen schon lange als Hilfsmittel, um die Einhaltung einer Spezifikation zu überprüfen. So testet eine assert-Anweisung in Java, ob der darauf folgende Ausdruck erfüllt ist. Sollte der Ausdruck nicht zutreffen, so erzeugt das Java-Laufzeitsystem eine Exception vom Typ AssertionError.Ähnlich verhalten sich die assert()-Anweisung des assert.h-Headers in C++ oder in C# die Assert-Methoden der Debug- oder Trace-Klasse aus dem System.Diagnostics-Namespace; diese kommen nur im Debug-Modus zur Ausführung. Um bereits zum Übersetzungszeitpunkt eine Assertion testen zu können, verfügt C++ über das static_assert-Keyword. In allen Fällen bricht das Programm ab, wenn die Bedingung nicht erfüllt wird.Assertion-Frameworks wie AssertJ oder Hamcrest arbeiten analog. Deren Konzept der deklarativen Definition von Asser­tions, um Bedingungen zu prüfen, hat in den verschiedenen Unit-Testing-Frameworks Eingang gefunden. So gehört Ham­crest bei JUnit bis zur Version 4 direkt zum ausgelieferten Open-Source-Package. Eine Assert-Anweisung in einem Unit-Test prüft, ob eine bestimmte Bedingung erfüllt ist. Trifft die zur Assert-Anweisung gehörende Bedingung zu, so hat das Testing-Framework den Testfall positiv ausgeführt – im negativen Fall wird die Ausführung als Fehler behandelt.Befinden sich mehrere Assertions in einem Testfall, so beendet das Testing-Framework dessen Ausführung, sobald die erste Assertion nicht erfüllt ist. Der Testfall wird als fehlerhaft gekennzeichnet und alle nachfolgenden Assertions kommen nicht mehr zur Ausführung. Aufgrund dieser Verhaltensweise sollte jeder Testfall möglichst nur mit einer Assertion versehen sein. Die durch das Unit-Testing-Framework (MSTest, NUnit, xUnit) bereitgestellte Assert-Anweisung lässt sich auch in Playwright nutzen.Playwright realisiert eigene Assertions für .NET/C# über die Expect-Klasse zusammen mit einem Web-spezifischen asynchronen Matcher: expect(locator).match-bedingung. Damit bietet Playwright eine ganze Reihe von Assertions an, um einzuhaltende Bedingungen vorzugeben. Bei jedem dieser Konstrukte prüft Playwright den übergebenen Locator, ob er die seitens der match-bedingung deklarierte Assertion einhält. Playwright testet den Locator, bis die durch den Matcher übergebene Bedingung erfüllt ist oder ein Time-out greift – ­dabei kommt beim Locator auch das Auto-Wait-Feature zum Einsatz. Standardmäßig gilt für Assertions in Playwright ein Time-out von fünf Sekunden.Die Not-Property einer Klasse verneint mittels Expect(page).Not die nachfolgende match-bedingung.Neben den Locator-Assertions verfügt Playwright zusätzlich über sogenannte APIResponseAssertions und PageAssertions. Während APIResponseAssertions sich für API-Tests eignen, zielen PageAssertions auf die Prüfung des Zustands ­einer Page ab. Die Klasse APIResponseAssertions realisiert nur ­eine Methode ToBeOKAsync(), die einen Status-Code im Bereich 200 … 299 sicherstellt. Die Klasse PageAssertions besitzt die beiden match-Bedingungen ToHaveTitleAsync und To­HaveURLAsync.

Fehlerhafte Playwright-Testfälle debuggen und Ursache analysieren

Einem Tester stehen sämtliche in der eingesetzten Entwicklungsumgebung (IDE) integrierten Testwerkzeuge für das Debugging eines fehlerhaften Testfalls zur Verfügung. In der Regel liefert bereits die IDE einen Hinweis, weshalb es zum Abbruch der Ausführung eines Testfalls kam. Für eine nähere Analyse des Fehlers fügt der Programmierer bei dessen Quellcode in der Nähe des Programmabbruchs einen Breakpoint in der IDE hinzu. Eine erneute Testausführung im Debugging-Mode ermöglicht mittels dieses Breakpoints eine systematische Fehleranalyse gemäß der innerhalb der IDE üblichen Vorgehensweise.Zusätzlich startet in einem .NET/C#-Projekt der Terminalbefehl PWDEBUG=1 HEADED=1 dotnet test <Name-Testfalldatei> die Ausführung der Testfälle im Browser und öffnet gleichzeitig den in Playwright integrierten Inspector im Debug-Modus (Bild 3). Dabei erscheint der Quellcode des Testfalls im Playwright Inspector. Dessen Toolzeile unterhalb der Titelzeile seines Fensters enthält zwei grüne Funktions-Icons. Die Optik dieser Icons ähnelt denen des Standard-Debuggers von Visual Studio/VS Code.

Das erste grüne Icon bietet die Funktion Resume ([F8]) an; diese führt die mit der aktuellen Cursor-Position verbundene Testmethode vollständig aus, während das zweite grüne Icon mit der Funktion Step over ([F10]) alle Zeilen im Quellcode der aktuellen Testmethode Zeile für Zeile nacheinander ausführt. Pa­rallel zum Playwright Inspector zeigt der geöffnete Browser das zur jeweiligen Zeile des Quellcodes gehörende Web-Element an.Da ein mit Playwright implementierter Testfall innerhalb eines Browsers abläuft, kann dessen fehlerhafter Abbruch auch mittels der DevTools des Browsers näher untersucht werden. Für diese Fehleranalyse muss Playwright den Testfall mit den beiden Umgebungsvariablen PWDEBUG=1 und HEADED=1 starten. Anschließend öffnet der Tester die DevTools des Browsers, um DOM-Elemente näher zu betrachten, über die Browser-Konsole Kommandos auszuführen, Konsolen-Logs zu analysieren oder Calls/Requests über das Netz zu verifizieren. Grundsätzlich steht dabei das playwright-Objekt im Fensterausschnitt Console für weitere Analysen zur Verfügung.Anhand der über Playwright bereitgestellten Locators erhält der Tester Zugriff auf die verschiedenen Playwright-Objekte innerhalb der Browser-Konsole. Diese Vorgehensweise zeigt das betroffene Web-Element im Browser-Fenster der App an. Alternativ hilft die inspect()-Methode, den übergebenen selector im Elements-Panel des DevTools im Detail zu untersuchen. Dabei hebt playwright.$(selector) das erste und playwright.$$(selector) alle Web-Elemente im Browser-Fenster der App für selector hervor. Der Konsolen-Befehl playwright.clear() entfernt wieder alle im Browser-Fenster der App vorhandenen Hervorhebungen.

Tracing unterstützt Analyse der Testausführung und Fehlersuche

Tracing beschreibt die Protokollierung des Ablaufs eines Programms, um dessen Ausführung insbesondere im Fehlerfall zu analysieren. Playwright besitzt für diesen Zweck ein GUI-Tool – den Playwright Trace Viewer. Dieses Werkzeug erlaubt es, während der Testausführung aufgezeichnete Traces/Logs zu lesen und den damit verbundenen Zustand der App zu betrachten. Die Aufzeichnung eines Traces erfolgt mittels des BrowserContext.Tracing-API. Anhand verschiedener Methoden beschreibt der Tester im Quellcode des Testfalls die konkrete Durchführung der Protokollierung.Dabei legt der Tester fest, wann, wie und über welchen Zeitraum während der Ausführung des Testfalls ein Trace erstellt wird. So gibt es eine Methode, um das Tracing zu starten (Tracing.StartAsync) und zu beenden (Tracing.Stop­Async). Optionen und Übergabeparameter legen fest, ob das Tracing Screenshots speichert, Netzwerkaktivitäten aufzeichnet, für jede Aktion des Testfalls DOM-Snapshots (Momentaufnahme des DOMs) protokolliert oder in welcher Datei das Trace gespeichert wird. Zur Aufzeichnung von Abhängigkeiten innerhalb desselben Browser-Kontexts stehen die Methoden Tracing.StartChunkAsync und Tracing.StopChunk­Async zur Verfügung.Das PowerShell-Skript pwsh bin/Debug/netX/playwright.ps1 show-trace trace.zip startet den Playwright Trace Viewer als eigenständige Anwendung. Alternativ erreicht ihn der URL trace.playwright.dev im Browser, anschließend öffnet der Tester per Drag-and-drop oder über dessen Schaltfläche Select file(s) die Trace-Datei (Bild 4). Ganz oben erscheint im Trace Viewer eine Zeitleiste; fährt der Tester mit der Maus über die dortigen Einträge, zeigt der Trace Viewer die ausgeführte Aktion in der Zeitleiste und mittig darunter das dazugehörende im Trace aufgezeichnete Objekt an.

Links unterhalb der Zeitleiste gibt es einen Fensterausschnitt mit den beiden Tabs Actions und Metadata. In Actions zeigt der Trace Viewer eine Liste aller von Playwright durchgeführten Aktionen an. Metadata gibt den Zeitpunkt, nähere Informationen zum Browser, den Viewport und die Anzahl der aufgezeichneten Seiten, Aktionen und Events aus. Rechts unterhalb der Zeitleiste erhält der Tester nähere Angaben zur Ausführung des Playwright-Befehls über das Register Call. Die Inhalte der rechts stehenden Register Console, Network, Source und Attachments liefern zusätzliche kontextbezogene Informationen.

Fussnoten

1. [1] Homepage von Playwright, https://playwright.dev/
2. [2] Frank Simon, Junges und vielversprechendes ­Werkzeugpaket, dotnetpro 10/2023, Seite 108 ff., http://www.dotnetpro.de/A2310Playwright
3. [3] Homepage von .NET, https://dotnet.microsoft.com/
4. [4] Homepage von JUnit, https://junit.org
5. [5] GitHub-Repository von MSTest (Microsoft Test Framework), https://github.com/microsoft/testfx
6. [6] Homepage von NUnit, https://nunit.org
7. [7] Homepage von pytest, https://docs.pytest.org/
8. [8] Homepage des pytest-Plug-ins für Playwright, http://www.dotnetpro.de/A2311Playwright1
9. [9] Homepage von pytest-xdist, http://www.dotnetpro.de/A2311Playwright2
10. Homepage von Maven, https://maven.apache.org/