{"id":6743,"date":"2026-06-16T10:17:35","date_gmt":"2026-06-16T08:17:35","guid":{"rendered":"https:\/\/www.clickstorm.de\/blog\/?p=6743"},"modified":"2026-06-16T10:27:14","modified_gmt":"2026-06-16T08:27:14","slug":"playwright-moderne-browser-tests","status":"publish","type":"post","link":"https:\/\/www.clickstorm.de\/blog\/playwright-moderne-browser-tests\/","title":{"rendered":"Playwright: Moderne Browser-Tests f\u00fcr Websites"},"content":{"rendered":"

Playwright ist ein modernes Tool f\u00fcr automatisierte Browser-Tests. Es hilft dabei, echte Nutzerinteraktionen im Browser zu testen: Seiten \u00f6ffnen, Buttons klicken, Formulare ausf\u00fcllen, Logins pr\u00fcfen oder komplette Checkout-Prozesse absichern.<\/p>\n

Nachdem wir in unserem letzten Beitrag gezeigt haben, wie wir mit Codeception automatisierte Browser-Tests in PHP schreiben, schauen wir uns diesmal Playwright an. Playwright ist f\u00fcr uns besonders spannend, weil es viele Funktionen direkt mitbringt, die bei modernen End-to-End-Tests wichtig sind: automatische Wartezeiten, Tests in mehreren Browsern, parallele Ausf\u00fchrung, Screenshots, Videos und einen sehr hilfreichen Trace Viewer.<\/p>\n

Wir nutzen Playwright aktuell noch nicht so lange und umfangreich wie Codeception. Dieser Beitrag ist deshalb kein Erfahrungsbericht aus vielen Jahren Projektpraxis, sondern eine fachliche Einordnung: Seit wann ist Playwright relevant? Welche Vorteile bietet es? Wie gelingt die Installation? Und welche Best Practices solltest du von Anfang an beachten?<\/p>\n

Seit wann ist Playwright relevant?<\/h2>\n

Playwright wurde von Microsoft entwickelt und ist seit 2020 verf\u00fcgbar. Die ersten 0.x-Versionen erschienen Anfang 2020, Playwright 1.0 folgte im Mai 2020. Seitdem wurde das Tool kontinuierlich weiterentwickelt und geh\u00f6rt heute zu den wichtigsten Werkzeugen f\u00fcr moderne End-to-End-Tests im Browser.<\/p>\n

Besonders relevant wurde Playwright, weil sich Webanwendungen in den letzten Jahren stark ver\u00e4ndert haben. Viele Websites laden Inhalte dynamisch nach, arbeiten mit JavaScript-Frameworks, komplexen Formularen, Cookie-Bannern, externen APIs und interaktiven Komponenten. Klassische Tests sto\u00dfen dabei schnell an Grenzen, wenn sie zu fr\u00fch klicken, auf noch nicht geladene Elemente zugreifen oder nur einen einzelnen Browser abdecken.<\/p>\n

Playwright setzt genau hier an: Es wurde f\u00fcr moderne Webanwendungen entwickelt und bringt viele Komfortfunktionen direkt mit.<\/p>\n

Was ist Playwright?<\/h2>\n

Playwright ist ein Open-Source-Framework f\u00fcr Web Testing und Browser-Automation. Mit Playwright lassen sich Tests f\u00fcr Chromium, Firefox und WebKit mit einer einheitlichen API schreiben. Der Playwright Test Runner ist speziell f\u00fcr End-to-End-Tests gedacht und bringt unter anderem Browser-Isolation, Auto-Waiting und web-first Assertions mit.<\/p>\n

Ein einfacher Playwright-Test sieht zum Beispiel so aus:<\/p>\n

import { test, expect } from '@playwright\/test';\r\n\r\ntest('Kontaktformular ist erreichbar', async ({ page }) => {\r\n  await page.goto('\/kontakt');\r\n\r\n  await expect(page.getByRole('heading', { name: 'Kontakt' })).toBeVisible();\r\n  await expect(page.getByLabel('E-Mail')).toBeVisible();\r\n});<\/pre>\n
Der Test \u00f6ffnet die Kontaktseite und pr\u00fcft, ob die \u00dcberschrift und das E-Mail-Feld sichtbar sind. Solche Tests k\u00f6nnen lokal, in CI\/CD-Prozessen oder in Container-Setups ausgef\u00fchrt werden.<\/p>\n
Welche Vorteile bietet Playwright?<\/h2>\n
Playwright wartet automatisch auf Elemente<\/h3>\n
Ein gro\u00dfer Vorteil von Playwright ist das automatische Warten. Bevor Playwright eine Aktion ausf\u00fchrt, pr\u00fcft es, ob ein Element wirklich sichtbar, stabil, aktiviert und bereit f\u00fcr die Interaktion ist. Die Playwright-Dokumentation nennt diese Pr\u00fcfungen \u201eActionability Checks\u201c. Erst wenn die Bedingungen erf\u00fcllt sind, wird zum Beispiel geklickt.<\/p>\n
Das reduziert typische Timing-Probleme. Statt \u00fcberall feste Wartezeiten einzubauen, kannst du dich st\u00e4rker auf echte Zust\u00e4nde konzentrieren:<\/p>\n
await page.getByRole('button', { name: 'Absenden' }).click();\r\nawait expect(page.getByText('Vielen Dank')).toBeVisible();<\/pre>\n
Nat\u00fcrlich macht Auto-Waiting Tests nicht automatisch perfekt. Wenn eine Anwendung instabil l\u00e4dt, externe Dienste h\u00e4ngen oder ein Selektor schlecht gew\u00e4hlt ist, k\u00f6nnen Tests weiterhin fehlschlagen. Aber Playwright nimmt dir viele klassische Warteprobleme ab.<\/p>\n
Playwright testet mehrere Browser<\/h3>\n
Playwright kann Tests in Chromium, Firefox und WebKit ausf\u00fchren. Damit lassen sich Unterschiede zwischen Browser-Engines fr\u00fch erkennen. Gerade WebKit ist interessant, weil es n\u00e4her an Safari liegt und damit f\u00fcr iOS-\/macOS-Nutzerinnen und Nutzer relevant ist.<\/p>\n
In der Konfiguration kannst du mehrere Projekte definieren:<\/p>\n
import { defineConfig, devices } from '@playwright\/test';\r\n\r\nexport default defineConfig({\r\n  projects: [\r\n    {\r\n      name: 'chromium',\r\n      use: { ...devices['Desktop Chrome'] },\r\n    },\r\n    {\r\n      name: 'firefox',\r\n      use: { ...devices['Desktop Firefox'] },\r\n    },\r\n    {\r\n      name: 'webkit',\r\n      use: { ...devices['Desktop Safari'] },\r\n    },\r\n  ],\r\n});<\/pre>\n
F\u00fcr viele Projekte reicht es am Anfang, nur mit Chromium zu starten. Sp\u00e4ter k\u00f6nnen Firefox und WebKit erg\u00e4nzt werden, wenn die Tests stabil laufen.<\/p>\n
Playwright bringt starke Debugging-Werkzeuge mit<\/h3>\n
Ein wichtiger Unterschied zu vielen \u00e4lteren Setups ist das Debugging. Playwright bringt mit dem Trace Viewer ein Werkzeug mit, mit dem sich Testl\u00e4ufe nachtr\u00e4glich analysieren lassen. Du kannst unter anderem die Timeline, DOM-Snapshots, Aktionen, Network Requests und Screenshots betrachten.<\/p>\n
Das ist besonders hilfreich, wenn Tests in der CI fehlschlagen, lokal aber funktionieren. Statt nur eine Fehlermeldung zu sehen, kannst du nachvollziehen, was der Browser tats\u00e4chlich gemacht hat.<\/p>\n
In der Konfiguration l\u00e4sst sich Tracing zum Beispiel so aktivieren:<\/p>\n
import { defineConfig } from '@playwright\/test';\r\n\r\nexport default defineConfig({\r\n  use: {\r\n    trace: 'on-first-retry',\r\n    screenshot: 'only-on-failure',\r\n    video: 'retain-on-failure',\r\n  },\r\n});<\/pre>\n
Damit werden Traces, Screenshots und Videos vor allem dann erzeugt, wenn sie wirklich gebraucht werden.<\/p>\n
Playwright f\u00fchrt Tests parallel aus<\/h3>\n
Playwright Test kann Tests parallel ausf\u00fchren. Daf\u00fcr nutzt es mehrere Worker-Prozesse. Das ist besonders interessant, wenn eine Testsuite w\u00e4chst und nicht mehr alle Tests nacheinander laufen sollen.<\/p>\n
F\u00fcr kleine Projekte ist das noch nicht entscheidend. Bei gr\u00f6\u00dferen Websites, Shops oder Webanwendungen kann Parallelisierung aber viel Zeit sparen \u2013 besonders in CI\/CD-Pipelines.<\/p>\n
Playwright hat gute Selektoren<\/h3>\n
Playwright empfiehlt nutzernahe Selektoren. Statt fragile CSS-Klassen wie .btn-primary:nth-child(2) zu verwenden, kannst du Elemente \u00fcber Rollen, Labels oder sichtbaren Text ausw\u00e4hlen:<\/p>\n
await page.getByRole('button', { name: 'Absenden' }).click();\r\nawait page.getByLabel('E-Mail').fill('max@example.de');\r\nawait expect(page.getByText('Vielen Dank')).toBeVisible();<\/pre>\n
Das hat zwei Vorteile: Die Tests lesen sich verst\u00e4ndlicher und sie orientieren sich st\u00e4rker daran, wie Nutzerinnen, Nutzer und assistive Technologien eine Seite wahrnehmen.<\/p>\n
Playwright installieren<\/h2>\n
Playwright l\u00e4sst sich in einem Node.js-Projekt sehr schnell einrichten. Die offizielle Installation l\u00e4uft \u00fcber:<\/p>\n
npm init playwright@latest<\/pre>\n
Alternativ kann Playwright in einem bestehenden Projekt manuell installiert werden:<\/p>\n
npm i -D @playwright\/test\r\nnpx playwright install<\/pre>\n
Die offizielle Playwright-Dokumentation nennt genau diese Installationswege.<\/p>\n
Falls du nach der Installation den Hinweis bekommst, dass Abh\u00e4ngigkeiten und Bibliotheken fehlen, dann kannst du folgendes Kommando ausf\u00fchren:<\/p>\n
npx playwright@latest install-deps<\/pre>\n
Beim Setup fragt Playwright typischerweise ab, ob TypeScript oder JavaScript verwendet werden soll, wo die Tests liegen sollen und ob ein GitHub-Actions-Workflow angelegt werden soll.<\/p>\n
Eine typische Struktur sieht danach ungef\u00e4hr so aus:<\/p>\n
playwright.config.ts\r\ntests\/\r\n  example.spec.ts\r\npackage.json<\/pre>\n
Playwright mit DDEV nutzen<\/h3>\n
Auch in DDEV-Projekten unterscheidet sich die Installation von Playwright grunds\u00e4tzlich nicht von anderen Setups, da Playwright \u00fcber Node.js installiert und ausgef\u00fchrt wird. Wichtig ist vor allem, dass die Tests gegen die richtige DDEV-URL laufen.<\/p>\n
Die Basis-URL kannst du in der playwright.config.ts<\/code> hinterlegen:<\/p>\n
import { defineConfig } from '@playwright\/test';\r\n\r\nexport default defineConfig({\r\n  use: {\r\n    baseURL: process.env.PLAYWRIGHT_BASE_URL || 'https:\/\/myproject.ddev.site',\r\n    trace: 'on-first-retry',\r\n    screenshot: 'only-on-failure',\r\n    video: 'retain-on-failure',\r\n  },\r\n});<\/pre>\n
Die Test-URL kann dann \u00fcber eine .env-Variable oder \u00fcber den CI-Prozess gesetzt werden:<\/p>\n
PLAYWRIGHT_BASE_URL=https:\/\/myproject.ddev.site<\/pre>\n
Wichtig: Lokale Projekt-URLs sollten m\u00f6glichst nicht fest in Git versioniert werden. F\u00fcr Teams ist es sauberer, mit Umgebungsvariablen zu arbeiten.<\/p>\n
Beispiel: Kontaktformular mit Playwright testen<\/h2>\n
Ein einfacher Test f\u00fcr ein Kontaktformular k\u00f6nnte so aussehen:<\/p>\n
import { test, expect } from '@playwright\/test';\r\n\r\ntest('Kontaktformular kann abgeschickt werden', async ({ page }) => {\r\n  await page.goto('\/kontakt');\r\n\r\n  await page.getByLabel('Name').fill('Max Mustermann');\r\n  await page.getByLabel('E-Mail').fill('max@example.de');\r\n  await page.getByLabel('Nachricht').fill('Das ist eine Testnachricht.');\r\n\r\n  await page.getByRole('button', { name: 'Absenden' }).click();\r\n\r\n  await expect(page.getByText('Vielen Dank')).toBeVisible();\r\n});<\/pre>\n
Der Test ist bewusst einfach gehalten. In echten Projekten kommen oft weitere Aspekte hinzu: Pflichtfelder, Validierungsfehler, Spam-Schutz, Cookie-Banner, Ajax-Verhalten oder mehrsprachige Formularvarianten.<\/p>\n
Playwright Tests ausf\u00fchren<\/h2>\n
Alle Tests lassen sich \u00fcber die Konsole starten:<\/p>\n
npx playwright test<\/pre>\n
Ein einzelner Test kann \u00fcber den Dateipfad gestartet werden:<\/p>\n
npx playwright test tests\/contact.spec.ts<\/pre>\n
F\u00fcr eine sichtbare Browser-Ausf\u00fchrung eignet sich:<\/p>\n
npx\u00a0playwright test --headed<\/pre>\n
Der UI Mode hilft beim Entwickeln und Debuggen:<\/p>\n
npx\u00a0playwright test --ui<\/pre>\n
Den HTML-Report \u00f6ffnest du mit:<\/p>\n
npx playwright show-report<\/pre>\n
Dein Browser \u00f6ffnet sich und du siehst eine Auflistung aller Tests.<\/p>\n
\"Playwright<\/p>\n
Bei fehlgeschlagenen Tests kannst du in den Trace Viewer wechseln und so jeden Schritt direkt im Browser nachvollziehen.<\/p>\n
\"Playwright<\/p>\n
Playwright in PhpStorm starten<\/h3>\n
Playwright-Tests lassen sich nicht nur \u00fcber die Konsole ausf\u00fchren, sondern auch direkt in PhpStorm starten. Das ist besonders praktisch, wenn du einzelne Tests w\u00e4hrend der Entwicklung schnell pr\u00fcfen m\u00f6chtest.<\/p>\n
Voraussetzung ist, dass Node.js im Projekt korrekt eingerichtet ist und Playwright wie oben beschrieben installiert wurde.<\/p>\n
Anschlie\u00dfend erkennt PhpStorm Playwright-Tests in der Regel direkt in den Testdateien. Du kannst einen Test dann \u00fcber das Run-Symbol neben dem Test oder \u00fcber das Kontextmen\u00fc starten.<\/p>\n
Playwright Best Practices<\/h2>\n
Nutze nutzernahe Selektoren<\/h3>\n
Bevor du CSS-Klassen verwendest, pr\u00fcfe, ob ein Element \u00fcber Rolle, Label oder Text erreichbar ist:<\/p>\n
await page.getByRole('button', { name: 'Speichern' }).click();\r\nawait page.getByLabel('E-Mail').fill('max@example.de');<\/pre>\n
Das macht Tests robuster und verst\u00e4ndlicher. Au\u00dferdem fallen Probleme mit Labels oder Buttons schneller auf.<\/p>\n
Vermeide feste Wartezeiten<\/h3>\n
Feste Wartezeiten machen Tests langsam und oft trotzdem instabil:<\/p>\n
await page.waitForTimeout(3000);<\/pre>\n
Besser ist es, auf sichtbare Zust\u00e4nde zu warten:<\/p>\n
await expect(page.getByText('Vielen Dank')).toBeVisible();<\/pre>\n
Oder auf ein bestimmtes Element:<\/p>\n
await expect(page.locator('.success-message')).toBeVisible();<\/pre>\n
Nutze Konstanten und Page Objects gezielt<\/h3>\n
Bei Playwright m\u00fcssen nicht alle Selektoren als Konstanten ausgelagert werden. Oft sind semantische Locator direkt im Test gut lesbar:<\/p>\n
await page.getByRole('button', { name: 'Absenden' }).click();\r\nawait page.getByLabel('E-Mail').fill('max@example.de');<\/pre>\n
Sinnvoll sind Konstanten vor allem f\u00fcr URLs, erwartete Texte, Testdaten oder technische Selektoren, die mehrfach verwendet werden:<\/p>\n
const URL_CONTACT = '\/kontakt';\r\nconst SUCCESS_MESSAGE = 'Vielen Dank';<\/pre>\n
Wenn Tests gr\u00f6\u00dfer werden, k\u00f6nnen Page Objects<\/a> helfen, wiederkehrende Abl\u00e4ufe sauber zu kapseln. So bleibt der eigentliche Test kurz und verst\u00e4ndlich.<\/p>\n
Halte Tests klein und verst\u00e4ndlich<\/h3>\n
Ein Test sollte m\u00f6glichst ein klares Szenario pr\u00fcfen. Statt einen riesigen Test zu schreiben, der Login, Suche, Formular, Warenkorb und Logout kombiniert, sind mehrere kleinere Tests oft besser wartbar.<\/p>\n
Gut:<\/p>\n
    \n
  • Login funktioniert<\/li>\n
  • Kontaktformular kann abgeschickt werden<\/li>\n
  • Suchfilter zeigt passende Ergebnisse<\/li>\n
  • Checkout erreicht Bestell\u00fcbersicht<\/li>\n<\/ul>\n
    Schlecht:<\/p>\n
      \n
    • Kompletter Website-Test mit allen Funktionen<\/li>\n<\/ul>\n
      Verwende Testdaten bewusst<\/h3>\n
      Tests sollten nicht von zuf\u00e4lligen Live-Daten abh\u00e4ngen. Wenn ein Test nur funktioniert, solange ein bestimmter Datensatz existiert, wird er schnell instabil.<\/p>\n
      Besser ist es, stabile Testdaten zu verwenden oder Daten gezielt vor dem Test anzulegen.<\/p>\n
      Speichere Zugangsdaten nicht im Repository<\/h3>\n
      Logins und Zugangsdaten geh\u00f6ren nicht in Git. Nutze Umgebungsvariablen:<\/p>\n
      TEST_USER=max@example.de\r\nTEST_PASS=secret<\/pre>\n
      Im Test:<\/p>\n
      await page.getByLabel('E-Mail').fill(process.env.TEST_USER || '');\r\nawait page.getByLabel('Passwort').fill(process.env.TEST_PASS || '');<\/pre>\n
      Aktiviere Trace, Screenshots und Videos gezielt<\/h3>\n
      F\u00fcr lokale Tests brauchst du nicht immer Videos. F\u00fcr fehlgeschlagene CI-L\u00e4ufe sind sie aber sehr hilfreich.<\/p>\n
      export default defineConfig({\r\n  use: {\r\n    trace: 'on-first-retry',\r\n    screenshot: 'only-on-failure',\r\n    video: 'retain-on-failure',\r\n  },\r\n});<\/pre>\n
      Starte mit wenigen kritischen Tests<\/h3>\n
      Gerade wenn Playwright neu eingef\u00fchrt wird, sollte nicht sofort die komplette Website automatisiert werden. Sinnvoller ist ein kleiner, stabiler Einstieg:<\/p>\n
        \n
      • Kontaktformular<\/li>\n
      • Login<\/li>\n
      • Cookie-Banner<\/li>\n
      • zentrale Suche<\/li>\n
      • Checkout oder Anfrageprozess<\/li>\n<\/ul>\n
        So zeigt sich schnell, ob Setup, Selektoren, Daten und CI-Prozess funktionieren.<\/p>\n
        Playwright oder Codeception?<\/h2>\n
        Wir nutzen in vielen Projekten aktuell Codeception f\u00fcr Browser-Tests. Das hat weiterhin gute Gr\u00fcnde: Codeception passt sehr gut in PHP-Projekte, Tests k\u00f6nnen in PHP geschrieben werden und das WebDriver-Modul erm\u00f6glicht Tests in echten Browsern \u00fcber das W3C-WebDriver-Protokoll.<\/p>\n
        Playwright bringt dagegen einige Vorteile mit, die vor allem bei modernen Browser-Tests spannend sind:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
        Thema<\/th>\nCodeception<\/th>\nPlaywright<\/th>\n<\/tr>\n<\/thead>\n
        Sprache<\/td>\nPHP<\/td>\nTypeScript\/JavaScript<\/td>\n<\/tr>\n
        Browser-Steuerung<\/td>\nWebDriver\/Selenium<\/td>\nPlaywright-eigene Browser-Automation<\/td>\n<\/tr>\n
        Auto-Waiting<\/td>\nm\u00f6glich, aber st\u00e4rker manuell gepr\u00e4gt<\/td>\nsehr stark integriert<\/td>\n<\/tr>\n
        Debugging<\/td>\nScreenshots, Reports, WebDriver-Logs<\/td>\nTrace Viewer, Screenshots, Videos, HTML-Report<\/td>\n<\/tr>\n
        Cross-Browser<\/td>\nm\u00f6glich \u00fcber WebDriver<\/td>\nChromium, Firefox, WebKit direkt integriert<\/td>\n<\/tr>\n
        Parallelisierung<\/td>\nm\u00f6glich, aber zus\u00e4tzlicher Aufwand<\/td>\ndirekt im Test Runner vorgesehen<\/td>\n<\/tr>\n
        Team-Fit<\/td>\nstark f\u00fcr PHP-Teams<\/td>\nstark f\u00fcr Frontend-\/JS-\/TS-Teams<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
         <\/p>\n
        F\u00fcr uns bedeutet das: Codeception bleibt f\u00fcr bestehende PHP-Projekte weiterhin sinnvoll. Playwright ist aber ein sehr spannender Kandidat f\u00fcr neue Projekte, frontendlastige Anwendungen oder Setups, bei denen Debugging, Parallelisierung und Cross-Browser-Tests besonders wichtig sind.<\/p>\n
        Und was ist mit Cypress?<\/h3>\n
        Cypress ist ebenfalls ein bekanntes Tool f\u00fcr End-to-End-Tests. Es bietet gute Entwicklerwerkzeuge und setzt ebenfalls auf Mechanismen, um dynamische Anwendungen besser testbar zu machen. Die Cypress-Dokumentation beschreibt zum Beispiel Retry-ability als Kernfunktion, mit der Commands, Queries und Assertions wiederholt werden k\u00f6nnen, um Tests stabiler zu machen.<\/p>\n
        Trotzdem sehen wir Cypress f\u00fcr unsere aktuelle Situation nicht als ersten Kandidaten. Ein Grund ist unser PHP-Schwerpunkt. Wenn wir aus dem PHP-Umfeld heraus in ein JavaScript-\/TypeScript-Testsetup wechseln, sollte der Mehrwert deutlich sein. Bei Playwright sehen wir diesen Mehrwert aktuell st\u00e4rker: vor allem durch den integrierten Cross-Browser-Ansatz, den Trace Viewer, die Parallelisierung und die sehr aktive Weiterentwicklung.<\/p>\n
        Auch die npm-Download-Zahlen zeigen, dass Playwright in den letzten Jahren stark an Bedeutung gewonnen hat. Solche Zahlen sind kein vollst\u00e4ndiger Marktanteil, weil Tools wie Selenium auch in anderen \u00d6kosystemen stark genutzt werden. Sie zeigen aber deutlich, dass Playwright im JavaScript-\/TypeScript-Umfeld aktuell sehr pr\u00e4sent ist.<\/p>\n
        \"Vergleich
        Quelle: https:\/\/npmtrends.com\/cypress-vs-playwright-vs-selenium-webdriver<\/p><\/div>\n
        Das hei\u00dft nicht, dass Cypress schlecht ist. F\u00fcr viele Frontend-Teams kann Cypress sehr gut passen. F\u00fcr uns wirkt Playwright im Moment aber wie der spannendere n\u00e4chste Schritt.<\/p>\n
        Video: Einstieg in Playwright<\/h2>\n
        In diesem Video bekommst du einen ersten Eindruck davon, wie Playwright eingerichtet wird und wie ein einfacher Browser-Test aussieht.<\/p>\n
        \"Info<\/p>\n
        Dieses Video wird \u00fcber eine externe Plattform (YouTube) gehostet. Das Laden bedarf der Zustimmung unserer Datenschutzbestimmungen.<\/a><\/p>\n
        Einstellung vornehmen<\/a><\/div>\n