Playwright-Tests lokal auszuführen ist der erste Schritt – wirklich nützlich werden sie aber erst, wenn sie automatisch bei jeder Code-Änderung laufen. Genau dafür eignet sich GitHub Actions: ein kostenloser CI-Server, der direkt in GitHub integriert ist und Tests bei jedem Push oder Pull Request automatisch ausführt.
In diesem Beitrag zeige ich dir Schritt für Schritt, wie ich ein neues Playwright-Projekt von Grund auf aufgesetzt, an GitHub angebunden und dort automatisch testen lassen habe – inklusive eines bewusst provozierten Fehlschlags, um die Fehleranalyse direkt in GitHub zu zeigen. Lasst uns starten! 🙂
Voraussetzungen
Für diesen Workflow brauchst du nur zwei Dinge:
Einen GitHub-Account
Git, installiert auf deinem Computer
Ob Git bereits installiert ist, lässt sich schnell prüfen:
git -v
Erscheint eine Ausgabe wie git version 2.39.5, ist alles bereit. Falls nicht, kannst du Git über git-scm.com/downloads für Mac oder Windows herunterladen und den Installationsanweisungen folgen.
Was ist eigentlich GitHub Actions?
Kurz zur Einordnung: GitHub Actions ist eine CI/CD-Plattform, die direkt in GitHub integriert ist. Statt einen separaten CI-Server wie Jenkins aufzusetzen, führt GitHub Actions automatisch definierte Aufgaben aus, sobald im Repository etwas passiert – zum Beispiel ein Push oder ein Pull Request.
Konfiguriert wird das über eine einfache YAML-Datei unter .github/workflows/, in der festgelegt wird, wann (Trigger) und was (z. B. Code auschecken, Abhängigkeiten installieren, Tests ausführen) automatisch laufen soll – und das für öffentliche Repositories komplett kostenlos.
Quelle: https://github.com/features/actions
Neues Playwright-Projekt aufsetzen
Zunächst wird ein neuer Projektordner angelegt und Playwright initialisiert:
mkdir playwright-ci-demo
cd playwright-ci-demo
npm init playwright@latest
Der Installationsassistent fragt dabei u. a., ob eine GitHub-Actions-Workflow-Datei direkt mit angelegt werden soll – diese Frage habe ich bewusst mit Yes beantwortet, dazu gleich mehr.
Playwright legt dabei automatisch eine Beispiel-Testdatei an (tests/example.spec.js), die zwei Tests enthält – einen Titel-Check und einen Klick-Test auf der Playwright-Website. Für dieses Tutorial reicht dieses Beispiel völlig aus, es geht hier ja um die CI-Pipeline und nicht um komplexe Testlogik:
Lokal ausgeführt mit:
npx playwright test
Passt 🙂
Repository auf GitHub anlegen
Als Nächstes wird ein neues Repository auf GitHub erstellt:
Im GitHub-Account auf New klicken
Einen aussagekräftigen Namen vergeben (z. B. playwright-ci-demo)
Optional eine Beschreibung ergänzen
Sichtbarkeit auf Public belassen (oder nach Bedarf anpassen)
Wichtig: Keine README, keine .gitignore und keine Lizenz auswählen – das Repository sollte komplett leer bleiben, da bereits ein bestehendes Projekt lokal vorliegt
Auf Create repository klicken
Tada:
Da das Playwright-Projekt bereits fertig aufgesetzt war (mit package.json, tests/, playwright.config.js usw.), aber noch kein lokales Git-Repository hatte, sah der Ablauf im Terminal so aus:
Zunächst wird eine .gitignore angelegt, damit node_modules und generierte Testreports nicht mit hochgeladen werden:
Anschließend werden alle Dateien zum ersten Commit hinzugefügt:
Zum Schluss wird das lokale Repository mit dem leeren GitHub-Repository verbunden und gepusht:
Nach einem Refresh der GitHub-Seite ist der komplette Projektcode im Repository sichtbar – inklusive der von Playwright automatisch erzeugten .github/workflows/playwright.yml.
GitHub Actions: Bereits fertig eingerichtet
Der praktische Nebeneffekt, „Yes” bei der Workflow-Frage im Setup-Assistenten geantwortet zu haben: Die Datei .github/workflows/playwright.yml war bereits im ersten Commit enthalten – ein manuelles Anlegen von Ordner und Datei entfällt damit komplett.
Ein Blick in die Datei zeigt die Standard-Vorlage von Playwright:
Kurz erklärt, was hier passiert:
on: Definiert, wann die Pipeline automatisch startet – bei jedem Push auf main/master sowie bei Pull Requests auf diese Branches
checkout / setup-node: Code auschecken und eine aktuelle Node.js-LTS-Version bereitstellen
npm ci / playwright install: Abhängigkeiten und Playwright-Browser installieren
npx playwright test: Der eigentliche Testlauf – lässt sich beliebig anpassen, z. B. auf eine bestimmte Spec-Datei oder einen bestimmten Browser
uses: upload-artifact: Der HTML-Report wird nach dem Lauf als Artefakt gespeichert, unabhängig davon, ob der Job erfolgreich war oder nicht (solange er nicht manuell abgebrochen wurde)
Da diese Datei bereits beim ersten Push mit hochgeladen wurde, war die Pipeline in diesem Fall schon automatisch gestartet, noch bevor überhaupt bewusst etwas an GitHub Actions eingerichtet wurde.
Pipeline im Einsatz
Ein Blick in den Actions-Tab auf GitHub zeigt direkt den ersten automatisch gestarteten Run, ausgelöst durch den initialen Push.
Nach Abschluss des Jobs (Dauer in diesem Fall 54s) steht auch direkt der generierte Playwright-Report als Artefakt zum Download bereit.
Klickt man auf den Job „test”, sieht man die einzelnen Steps mit ihrer jeweiligen Dauer. Auffällig: „Install Playwright Browsers” nimmt mit Abstand am meisten Zeit in Anspruch (in diesem Lauf ca. 40 Sekunden), da der Runner bei jedem Job komplett neu aufgesetzt wird.
Klickt man speziell auf den Step „Run Playwright tests”, klappt sich das Log mit dem eigentlichen Testergebnis auf:
Bessere Übersicht mit dem GitHub-Reporter
Ein reines „2 passed” gibt bei einem Fehlschlag wenig Aufschluss. Playwright bringt dafür einen eigenen GitHub-Reporter mit, der Testergebnisse direkt als Annotations im Job-Summary anzeigt.
Dafür wird in der playwright.config.js ein zweiter Reporter ergänzt:
Um den Effekt direkt zu sehen, habe ich zusätzlich einen Test bewusst zum Scheitern gebracht – durch eine absichtlich falsche Erwartung:
Beide Änderungen zusammen committet und gepusht:
Spannender Nebeneffekt: In playwright.config.js steht standardmäßig folgende Zeile:
Das bedeutet: Nur auf CI-Servern wird ein fehlgeschlagener Test automatisch zweimal wiederholt, bevor er endgültig als „failed” gilt. Im Log sind entsprechend „Retry #1″ und „Retry #2″ zu sehen, bevor der Test final als fehlgeschlagen gewertet wird – erklärt auch, warum der Job insgesamt deutlich länger läuft als beim erfolgreichen Durchlauf.
Auf der Run-Übersichtsseite erscheint jetzt ein neuer Abschnitt Annotations mit den Fehlerdetails:
Das liefert genug Kontext, um den Fehler direkt einzugrenzen – Datei, Zeile, erwarteter und tatsächlicher Wert – ohne den kompletten HTML-Report herunterladen zu müssen.
Jobs erneut ausführen
Soll ein Job noch einmal laufen – etwa nach einem Fix, oder um einen fehlgeschlagenen Lauf nochmal mit demselben Code zu wiederholen – lässt sich das direkt über GitHub steuern, ohne erneut Code pushen zu müssen. Über das Dropdown-Menü am Job stehen zwei Optionen zur Verfügung:
Re-run all jobs: Führt die komplette Pipeline erneut aus
Re-run failed jobs: Wiederholt nur die fehlgeschlagenen Jobs
Da es in diesem einfachen Setup nur einen einzigen Job (test) gibt, führen beide Optionen zum gleichen Ergebnis.
Natürlich lässt sich der absichtlich kaputte Test auch einfach wieder reparieren und final pushen, um die Pipeline mit einem sauberen, grünen Ergebnis abzuschließen:
Fazit
Playwright-Tests über GitHub Actions laufen zu lassen, ist mit überschaubarem Aufwand verbunden: Projekt aufsetzen, Repository anlegen, Code pushen – die Workflow-Datei bringt der Playwright-Setup-Assistent auf Wunsch direkt mit.
Der große Mehrwert entsteht dadurch, dass Tests ab sofort automatisch bei jedem Push oder Pull Request laufen, ganz ohne manuellen Aufwand und komplett kostenlos.
Mit dem zusätzlichen GitHub-Reporter lassen sich Fehler außerdem deutlich schneller eingrenzen, ohne den vollständigen HTML-Report herunterladen zu müssen – gerade bei größeren Test-Suiten ein echter Zeitgewinn. Und die automatischen Retries auf CI sorgen zusätzlich dafür, dass vereinzelte Flaky-Tests nicht sofort die ganze Pipeline rot färben.
