Ein belastbares Playwright-Fundament

Ein belastbares Playwright-Fundament

0:00 Dieses Modul ist der Teil, den man beim Thema KI gern überspringt — und genau deshalb steht er hier vorne. Wer beurteilen will, ob ein erzeugter Test etwas taugt, muss die Bausteine kennen, aus denen er besteht: Locators, Assertions, Isolation, Traces. Das sind vier Begriffe, und mit ihnen lässt sich fast jeder Agentenvorschlag bewerten. Ohne sie bleibt nur Vertrauen.

0:21 Wir gehen sie in den nächsten drei Kapiteln durch, jeweils an unserem Pflanzenversand, und Sie werden merken: Die meisten Fehler erzeugter Tests sind Verstöße gegen genau diese vier Grundlagen.

Das Testmodell von Playwright

0:33 Fangen wir mit der Architektur an. Wer versteht, was Playwright bei einem Testlauf eigentlich startet und wo die Grenzen zwischen den Tests verlaufen, hat die halbe Fehlersuche schon gewonnen. Es geht in diesem Kapitel nicht um Vollständigkeit, sondern um die vier, fünf Begriffe, die Sie später beim Lesen erzeugter Tests wirklich brauchen.

0:52 Fangen wir mit dem an, was beim Start eines Testlaufs tatsächlich passiert. Denken Sie an ein Hotel. Der Browser ist das Gebäude, das einmal aufgesperrt wird. Der Browser Context ist ein Zimmer: eigener Schlüssel, eigene Minibar, eigener Zustand — und wenn der Gast auszieht, wird alles zurückgesetzt. Die Page ist der Schreibtisch in diesem Zimmer. Entscheidend ist der Kontext: Er trägt Cookies, Speicher und Sitzung, und jeder Test bekommt einen frischen.

1:19 Deshalb kann kein Test einem anderen seinen Zustand vererben — nicht weil jemand sorgfältig aufräumt, sondern weil das Zimmer neu bezogen wird. Die Tabelle zeigt eine Hierarchie, und die Kostenverteilung darin ist der Grund, warum Playwright so schnell ist. Einen Browser zu starten ist teuer, deshalb passiert das einmal pro Worker-Prozess.

1:39 Einen Kontext zu öffnen ist dagegen fast umsonst — deshalb bekommt ihn jeder Test neu, und Isolation ist kein Luxus, sondern der Normalfall. Aus dieser Ökonomie folgt alles Weitere: Sie müssen sich zwischen Geschwindigkeit und Isolation nicht entscheiden. Wenn ein erzeugter Test später trotzdem von seinem Vorgänger abhängt, ist das keine technische Notwendigkeit, sondern ein Fehler.

2:02 Isolation klingt nach einer Aufräum-Tugend, ist aber eine handfeste Diagnose-Eigenschaft. Ein isolierter Test darf in beliebiger Reihenfolge laufen und zeigt trotzdem dasselbe — das heißt, sein Fehlschlag sagt etwas über genau diese eine Sache aus und nicht über die Vorgeschichte. Parallelität wird überhaupt erst dadurch möglich. Und jetzt der Punkt, der uns durch das ganze Seminar begleitet: Erzeugte Tests verletzen diese Regel besonders gern.

2:27 Ein Agent, der eine Anwendung erkundet hat, schreibt gern den ganzen Weg auf, den er gegangen ist — inklusive der Voraussetzungen aus dem Schritt davor. Was Sie hier sehen, ist das Grundmuster jedes Playwright-Tests: erst den Zustand herstellen, dann handeln, dann behaupten. Die interessante Stelle ist der Parameter in der Testfunktion.

2:46 Diese sogenannte Fixture liefert der Runner — und mit ihr kommt der frische Kontext, über den wir eben gesprochen haben. Sie müssen also nichts aufräumen und nichts initialisieren; Sie bekommen eine saubere Umgebung geliefert. Merken Sie sich dieses Muster gut: Ab Modul acht bauen wir uns eigene Fixtures, und dann zeigt sich, wie viel Setup dieser eine Mechanismus aus den Tests heraushalten kann.

3:10 Projekte sind Playwrights Antwort auf die Frage: Womit soll dieser Test laufen — welcher Browser, welches Gerät, welcher Ausgangszustand? Die Versuchung ist groß, sofort alle Browser einzuschalten. Machen Sie das nicht: Sie verdreifachen die Laufzeit und prüfen dreimal dasselbe. Ein Projekt pro Browser nur dort, wo die Anwendung sich wirklich unterschiedlich verhält. Sinnvoller ist ein vorgeschaltetes Setup-Projekt für die Anmeldung.

3:35 Und die Basisadresse gehört in die Konfiguration, nicht in den Test — sonst können Sie die Suite nie gegen eine zweite Umgebung fahren.

Robuste Interaktionen schreiben

3:44 Damit steht das Gerüst. Jetzt zur Stelle, an der die meisten Tests brechen: Wie findet ein Test ein Element auf der Seite, und wie stellt er fest, dass etwas stimmt? Das sind die zwei Stellen, an denen erzeugter Code am häufigsten kippt — und gleichzeitig die, an denen sich schlechte Qualität am schnellsten erkennen lässt.

4:02 Entsprechend gründlich schauen wir hin. Ein Locator ist keine Referenz auf ein Element, sondern eine Beschreibung davon — so, wie Sie am Telefon jemandem den Weg beschreiben, statt ihn an die Hand zu nehmen. Aufgelöst wird die Beschreibung erst im Moment des Zugriffs, und Playwright wartet dabei von selbst, bis das Element sichtbar und bedienbar ist.

4:22 Das nennt sich Auto-Waiting und nimmt Ihnen erstaunlich viel Arbeit ab. Der zweite Gedanke ist noch wichtiger: Gute Locators fragen nach Rolle, Beschriftung oder Text — also nach dem, was auch ein Mensch auf der Seite sieht. Die Reihenfolge in dieser Tabelle ist eine Rangfolge, und dahinter steckt ein Prinzip: Je näher ein Locator an der Wahrnehmung eines Menschen liegt, desto länger hält er.

4:45 Eine Schaltfläche mit der Aufschrift „Kaufen" heißt auch nach dem nächsten Redesign noch so; die generierte CSS-Klasse dahinter überlebt keinen Build. Rollenbasierte Locators haben einen angenehmen Nebeneffekt: Sie finden das Element nur, wenn es für Screenreader überhaupt erreichbar ist — Sie testen also nebenbei ein Stück Barrierefreiheit.

5:04 Test-IDs sind legitim, aber sie sind eine bewusste Entscheidung, kein Standardweg. Feste Wartezeiten sind der Klassiker unter den schlechten Angewohnheiten, und man versteht sofort, warum sie entstehen: Der Test war rot, zwei Sekunden Pause haben geholfen, Problem gelöst. Nur ist es das nicht. Die Pause verlängert jeden einzelnen Lauf, auch wenn die Anwendung längst bereit ist. Sie verdeckt ein echtes Ladeproblem, statt es zu zeigen.

5:29 Und auf einer langsameren CI-Maschine reichen die zwei Sekunden irgendwann nicht mehr — dann ist der Test nicht mehr kaputt, sondern launisch, und das ist deutlich schwerer zu reparieren. Diese fünf Zeilen sind eine kleine Sammlung von Werkzeugen, die Sie ständig brauchen werden. Gemeinsam ist ihnen, dass sie nicht einmal prüfen, sondern bis zum Zeitlimit wiederholen — deshalb braucht daneben keine Pause zu stehen.

5:54 Achten Sie auf die Unterschiede in der Aussagekraft: dass ein Element sichtbar ist, sagt fast nichts; welchen Text es trägt, sagt viel. Und die letzte Zeile ist die, die in erzeugtem Code am häufigsten fehlt: die negative Assertion. Ein Fehlerfall gilt erst dann als abgesichert, wenn jemand behauptet, dass die Meldung eben nicht erscheint.

6:14 Diese vier Fallen begegnen uns später alle noch einmal — beim Review erzeugter Tests. Der erste Punkt entsteht durch Codegen und durch Agenten, die nehmen, was sie im DOM finden. Der zweite ist tückisch: Ein Locator, der mehrere Elemente trifft, funktioniert oft monatelang, bis die Seite ein zweites Exemplar bekommt. Der dritte ist der häufigste Qualitätsmangel überhaupt — Sichtbarkeit statt Inhalt zu prüfen.

6:38 Und der vierte kostet Sie den halben Nutzen der Testsuite: Wer nur Erfolgsfälle absichert, merkt nicht, wenn die Fehlerbehandlung verschwindet.

Tests ausführen und Fehler verstehen

6:47 Bleibt das dritte Standbein: Was tun, wenn ein Test rot ist? Playwright bringt dafür Werkzeuge mit, die viele gar nicht kennen — und eines davon ist so gut, dass es die Arbeitsweise verändert. Rot ist kein Zustand, sondern eine Frage. Playwright bringt für die Antwort erstaunlich gute Werkzeuge mit, und eines davon verändert die Arbeitsweise dauerhaft, sobald man es einmal benutzt hat.

7:10 Das Werkzeug, das ich meine, ist der Trace. Man kann ihn sich vorstellen wie den Flugschreiber eines Testlaufs: Er zeichnet jede Aktion auf, dazu den Zustand der Seite in genau diesem Moment, den Netzwerkverkehr und die Konsolenausgaben — und das alles auf einer gemeinsamen Zeitachse, durch die Sie hinterher scrollen können.

7:28 Daneben gibt es den UI Mode für den interaktiven Lauf, den Inspector zum schrittweisen Nachvollziehen und Codegen zum Aufzeichnen. Der Trace ist aber der Zeuge, auf den es ankommt, gerade wenn ein Fehler nur in der Pipeline auftritt. Diese Reihenfolge ist wichtiger, als sie aussieht, denn sie verhindert den häufigsten Fehler bei der Fehlersuche: zu früh zu wissen, was los ist.

7:49 Erst reproduzieren, dann den Trace öffnen. Dann zur letzten erfolgreichen Aktion springen und sich anschauen, wie die Seite dort tatsächlich aussah — sehr oft ist das erwartete Element noch da und heißt nur anders. Danach Netzwerk und Konsole, denn manches Problem liegt gar nicht im Browser. Und erst am Ende die Entscheidung: Testfehler, Umgebungsfehler oder echter Produktfehler.

8:11 Diese Klassifikation begleitet uns bis ins Healer-Modul. Vier Befehle, vier Arbeitsweisen. Der UI Mode ist der angenehmste Einstieg — man sieht die Suite, kann einzelne Tests wiederholen und in der Zeitachse blättern. Der Debug-Modus hält den Browser an und lässt Sie Schritt für Schritt weitergehen. Codegen zeichnet auf, was Sie in der Anwendung tun, und schreibt Testcode mit — und zwar mit Locators nach Rolle, Text und Test-ID, also genau nach der Rangfolge von eben.

8:39 Der letzte Befehl öffnet einen gespeicherten Trace. Nehmen Sie sich fünf Minuten für den Trace Viewer, er zahlt sich schneller aus als jedes andere Werkzeug hier. Der Vergleich in dieser Tabelle wird in der Praxis oft falsch gewichtet. Viele Teams schalten Videos ein und finden sie beruhigend — aber ein Video zeigt, dass etwas schiefging, nicht warum.

8:59 Der Trace beantwortet beide Fragen zugleich, weil er die Aktion des Tests und die Reaktion der Seite nebeneinanderlegt. Screenshots sind gut für den schnellen Blick, der Report für die Übersicht über den ganzen Lauf. Meine Empfehlung: Traces beim ersten Wiederholungsversuch einschalten und in der Pipeline aufbewahren. Videos sind ein Zusatz, kein Ersatz.

9:21 Ihre Aufgabe: Nehmen Sie einen rot gelaufenen Test und begründen Sie anhand der Artefakte, ob das Problem am Test oder am Produkt liegt. Das Erfolgskriterium ist bewusst streng — eine Einordnung zählt nur mit Belegstelle aus dem Trace, nicht mit einer Vermutung. Diese Fähigkeit ist die Eintrittskarte für das Healer-Modul: Ein Agent, der Tests repariert, braucht jemanden, der entscheidet, ob überhaupt der Test das Problem ist.

9:45 Wer mag, ändert zusätzlich eine Beschriftung in der Anwendung und beobachtet, welche Assertion als Erste bricht. Zum Abschluss vier Punkte, die alle mit Bequemlichkeit zu tun haben. Traces nur lokal einzuschalten ist besonders ärgerlich, weil die schwierigen Fehler in der Pipeline auftreten und man dort dann nichts in der Hand hat.

10:04 Einen Fehlschlag durch Wiederholung wegzudrücken fühlt sich effizient an und verschiebt das Problem um genau eine Woche. Codegen-Ausgabe ungefiltert zu übernehmen bringt Klicks in den Test, die niemand braucht. Und der Report ist ein Nachweis über den Lauf, nicht über die Qualität der Behauptungen. Damit haben wir das Fundament — im nächsten Modul kommt der Agent dazu.