Playwright-Tests in der CI-Pipeline

Playwright-Tests in der CI-Pipeline

0:00 Eine Testsuite entfaltet ihren Wert erst, wenn sie ohne Aufforderung läuft — und wenn ein rotes Ergebnis etwas verhindert. In diesem Modul bringen wir unsere Tests in die Pipeline. Das ist technisch überschaubar; der offizielle Workflow passt auf eine Folie. Anspruchsvoller ist die Frage davor: Welcher Lauf läuft wann, wie gehen wir mit launischen Tests um, und was passiert eigentlich, wenn ein Agent eine Änderung vorschlägt?

0:25 Am Ende schließt sich damit der Kreis zu Modul sechs.

Eine CI-Teststrategie entwerfen

0:28 Vor der ersten Zeile YAML steht eine Entscheidung, die viele überspringen — und die darüber bestimmt, ob die Pipeline in einem halben Jahr noch ernst genommen wird. Diese Entscheidung fällt man einmal und lebt danach jahrelang damit. Sie kostet eine halbe Stunde und verhindert die Pipeline, auf die am Ende niemand mehr wartet.

0:46 Eine CI-Teststrategie legt fest, welche Tests bei welchem Ereignis laufen, wie lange das dauern darf und was mit einem roten Lauf geschieht. Ohne diese Festlegung wächst die Pipeline, bis niemand mehr auf sie wartet. Und dann passiert das, was man in vielen Teams beobachten kann: Der rote Lauf wird zur Hintergrundmusik, jemand merged trotzdem, und irgendwann fragt keiner mehr.

1:08 Die Strategie ist deshalb weniger ein technisches als ein soziales Dokument — sie regelt, worauf sich alle verlassen können. Die Logik hinter dieser Tabelle ist eine einfache Abwägung: Je früher im Ablauf, desto kürzer der Lauf. Beim Push zählt Geschwindigkeit — eine Rauchtest-Auswahl von wenigen Minuten. Beim Pull Request zählt Vollständigkeit, dort läuft die Regression.

1:31 Nachts läuft, was teuer und nicht dringend ist, etwa die Browsermatrix. Und vor einem Release läuft alles, inklusive der Quarantäne-Prüfung. Wichtiger als jede dieser Zeilen ist die Fußnote: Ein roter Lauf muss etwas verhindern. Sonst ist die Pipeline Dekoration. Vier Festlegungen, die man einmal trifft und dann nicht mehr diskutiert. Wie viele Wiederholungen sind erlaubt, bevor ein Test als instabil gilt?

1:56 Wohin wandern instabile Tests, und wer holt sie zurück — ohne benannte Person passiert das nie. Welche Geheimnisse kennt die Pipeline und woher kommen sie? Und welche Artefakte werden wie lange aufbewahrt? Der letzte Punkt klingt nach Verwaltung, entscheidet aber darüber, ob Sie einen Fehler von letzter Woche noch nachvollziehen können.

2:16 Fünf Schritte gegen ein Problem, das sich gern versteckt. Wiederholungen in CI zulassen, aber jeden Retry im Report ausweisen — das ist der entscheidende Punkt, denn sonst verschwindet die Instabilität hinter einem grünen Haken. Tests mit Retry-Erfolg regelmäßig auswerten, nicht nur zur Kenntnis nehmen. Wiederholt auffällige Tests markieren und in einen eigenen Lauf ziehen.

2:38 Für jeden markierten Test ein Ticket mit Frist — ohne Frist bleibt die Quarantäne ein Endlager. Und die Traces dieser Läufe aufbewahren, sonst fehlt später die Grundlage. Vier Fallen, die alle bequem sind. Wiederholungen hochzusetzen, bis die Pipeline grün ist, löst genau nichts und verschleiert alles. Artefakte nur bei Fehlschlag zu erzeugen, nimmt Ihnen den Vergleich mit einem gesunden Lauf — und der ist bei Timing-Problemen Gold wert.

3:04 Geheimnisse in die Workflow-Datei zu schreiben statt in die Secrets ist ein Fehler, der erstaunlich oft passiert, weil es beim Ausprobieren so praktisch ist. Und instabile Tests dauerhaft zu überspringen, ohne dass es jemand merkt, ist die stille Variante des Qualitätsverlusts.

Einen GitHub-Actions-Workflow bauen

3:20 Jetzt zum handwerklichen Teil. Sie werden überrascht sein, wie wenig es braucht — und an welcher unscheinbaren Stelle die meisten Läufe scheitern. Die Grundform passt auf eine Folie, und das ist keine Vereinfachung für das Seminar — sie steht so auch in der Dokumentation. Interessant wird es an einer einzigen, unscheinbaren Zeile.

3:40 Ein Playwright-Workflow besteht aus wenigen Schritten: auschecken, Node bereitstellen, Abhängigkeiten installieren, Browser samt Systempaketen installieren, Tests ausführen, Report hochladen. Das ist die Grundform, und sie steht so auch in der offiziellen Dokumentation. Alles Weitere — Sharding, Matrix, Zeitlimits — kommt darauf.

4:00 Der Rat lautet ausdrücklich: Fangen Sie mit der Grundform an und erweitern Sie erst, wenn die Laufzeit es verlangt. Ein komplizierter Workflow, den niemand versteht, ist beim ersten Fehler ein Problem für sich. Zehn Zeilen, und die unscheinbarste ist die wichtigste: der Installationsschritt mit dem Zusatz für die Systempakete.

4:20 Auf Ihrem Rechner sind die Bibliotheken, die ein Browser braucht, längst vorhanden — auf einem frischen Runner nicht. Fehlt dieser Zusatz, startet der Browser gar nicht erst, und die Fehlermeldung führt in die Irre. Zweiter Punkt: das Zeitlimit. Ohne Limit hängt ein blockierter Lauf eine Stunde lang, und bei jedem weiteren Push wächst die Warteschlange.

4:41 Zwei Ergänzungen. Der Upload-Schritt sichert den Report auch dann, wenn der Lauf rot war — genau dann brauchen Sie ihn ja. Achten Sie auf die Bedingung: nicht bei Erfolg, sondern immer, solange der Job nicht abgebrochen wurde. Die Matrix-Strategie darunter teilt die Suite auf vier Jobs auf. Was hier nicht mehr draufpasst, aber dazugehört: Jeder Job schreibt dann einen Blob-Bericht, und ein abschließender Job führt sie zusammen.

5:05 Ohne diesen letzten Schritt haben Sie vier Teilergebnisse und keinen Überblick. Ein Punkt, an dem viele Zeit investieren und nichts gewinnen. Das Wiederherstellen aus dem Cache dauert etwa so lange wie das Herunterladen — der Nutzen ist also nahe null. Schlimmer: Ein Cache-Treffer über Versionsgrenzen hinweg liefert falsche Binärdateien, und der resultierende Fehler ist schwer zu finden.

5:28 Wenn überhaupt, muss der Cache an den Playwright-Versionshash gebunden werden. Die ehrliche Empfehlung lautet: Lassen Sie es. Der Hebel liegt bei Testlaufzeit und Sharding, nicht bei den Browser-Downloads.

CI-Läufe stabilisieren

5:41 Bleibt das Phänomen, das Nerven kostet: Tests, die lokal grün und in der Pipeline rot sind. Fast immer steckt ein Unterschied dahinter, den man benennen kann. Der Klassiker: lokal grün, in der Pipeline rot. Das ist kein Schicksal, sondern eine Liste von Unterschieden, die man abarbeiten kann — und die kürzer ist, als man denkt.

6:02 Ein stabiler CI-Lauf unterscheidet sich möglichst wenig vom lokalen Lauf: gleiche Node-Version, gleiche Browser, gleiche Testdaten. Wo das nicht möglich ist, wird der Unterschied bewusst gesetzt — etwa die geringere Worker-Zahl, damit jeder Test die vollen Ressourcen bekommt. Bewusst ist hier das Schlüsselwort. Ein Unterschied, den Sie kennen und begründen können, ist harmlos; ein Unterschied, den niemand bemerkt hat, kostet Sie einen halben Tag Suche.

6:29 Fünf Schritte, vom Einfachen zum Aufwendigen. Node-Version und Abhängigkeiten über die Lockdatei festnageln. Nur die Browser installieren, die Sie wirklich brauchen — das spart bei jedem Lauf. Die Worker-Zahl bewusst setzen, statt sie der Maschine zu überlassen. Bei zäher Reproduktion einen Container als feste Laufzeit einsetzen; das offizielle Playwright-Image nimmt Ihnen mehrere Fehlerquellen auf einmal ab.

6:54 Und der wichtigste Schritt: Fehlschläge lokal mit den CI-Artefakten nachstellen, statt zu raten. Dafür haben Sie die Traces aufbewahrt. Vier Ursachen, die zusammen den größten Teil der Fälle abdecken. Weniger Ressourcen und andere Zeiten treffen genau die Tests, die feste Pausen benutzen — noch ein Argument für Web-first Assertions.

7:15 Eine andere Zeitzone oder Sprache verschiebt Datumsformate und Meldungstexte; beides gehört in die Konfiguration. Fehlende Systempakete kennen wir. Und andere Testdaten sind der Bogen zu Modul zehn. Die Fußnote ist ein guter Rat: Ein Container mit dem offiziellen Image nimmt drei dieser vier Ursachen auf einen Schlag weg.

7:35 Damit schließt sich der Kreis dieses Seminars. Vier Gründe, warum jede Agentenänderung denselben Weg nimmt wie menschlicher Code. Der Diff wird von Menschen gelesen, bevor er wirkt. Die Pipeline prüft ihn unter denselben Bedingungen wie alles andere. Übersprungene oder abgeschwächte Tests fallen im Review auf — das ist die Stelle, an der die Guardrails aus Modul sechs tatsächlich greifen.

7:58 Und die Historie bleibt nachvollziehbar, inklusive Begründung. Kein Sonderweg für Agenten: Das ist die vielleicht wichtigste Betriebsregel überhaupt. Ihre Aufgabe: Betreiben Sie die Suite so in CI, dass Ergebnisse reproduzierbar und auswertbar sind. Drei Dinge müssen stimmen — ein Pull Request löst den Lauf aus, der HTML-Report liegt als Artefakt bei, und ein Fehlschlag blockiert den Merge.

8:22 Besonders der dritte Punkt ist die eigentliche Prüfung: Er macht aus einem Testlauf eine Wirkung. Wer schneller fertig ist, verteilt die Suite auf vier Shards und führt die Berichte zusammen. Im Abschlussmodul setzen wir dann alles zu einem durchgehenden Fall zusammen.