Oberflächentests mit Playwright

Einleitung

Oberflächentests (UI-Tests) stellen sicher, dass Webanwendungen sich so verhalten, wie es Benutzer erwarten – unabhängig vom internen Code. Mit Playwright steht ein modernes, mächtiges Test-Framework zur Verfügung, das speziell für dynamische Web-UIs entwickelt wurde. Dieser Artikel stellt Playwright vor, zeigt seinen Einsatz in einem typischen Projekt mit SvelteKit und vergleicht es mit Alternativen wie Cypress und Selenium. Darüber hinaus werden praktische Strategien zur Teststruktur, Fehlervermeidung und Debugging vermittelt.

Was ist Playwright?

Playwright ist ein von Microsoft entwickeltes Open-Source-Tool für UI-Tests von Webanwendungen. Tests werden in echten Browserinstanzen (Chromium, Firefox, WebKit) ausgeführt und über DevTools-Protokolle gesteuert. Besonders hervorzuheben sind:

Typischer Playwright-Workflow

Playwright erkennt standardmäßig alle Testdateien mit den Endungen .spec.ts oder .test.ts. Es ist also üblich, Testdateien nach dem Schema xyz.spec.ts zu benennen. Dies ist keine Pflicht, aber eine empfohlene Konvention, da sie vom Test-Runner automatisch erkannt wird.

Ein vollständiger Testdurchlauf mit Playwright besteht in der Regel aus drei Schritten:

  1. Test schreiben

    • Der Test wird als JavaScript- oder TypeScript-Datei im e2e/-Verzeichnis abgelegt.

    • Beispiel:

      test('zeigt Loginformular', async ({ page }) => {
  await page.goto('/login');
  await expect(page.locator('form')).toBeVisible();
});

  2. Test ausführen

    • Im Terminal ausführen:

      npx playwright test

    • Optional: Nur bestimmte Tests oder Dateien ausführen:

      npx playwright test login.spec.ts

  3. Ergebnisse analysieren

    • Playwright gibt im Terminal an, ob Tests bestanden oder fehlgeschlagen sind.

    • Bei Fehlern:

      • Trace-Dateien oder Screenshots analysieren

      • Optional: --debug oder --trace on verwenden

      Beispiel:

      npx playwright show-trace trace.zip

Dieser Workflow ist die Grundlage für einfache lokale Tests, funktioniert aber auch identisch in CI/CD-Umgebungen (z. B. GitHub Actions).

Automatische Warte-Mechanismen

Playwright wartet intelligent und automatisch auf Ereignisse im DOM. Das bedeutet: Wenn du z. B. ein Element anklickst oder eine Seite neu lädst, wartet Playwright so lange, bis die Seite bereit ist (Ladezustand, Sichtbarkeit, Interaktivität), ohne dass du explizit wait-Befehle schreiben musst. Das reduziert Fehler durch Timing-Probleme erheblich und macht Tests stabiler als bei älteren Tools wie Selenium.

Beispiel:

await page.click('text=Speichern'); // wartet intern, bis der Button sichtbar & klickbar ist

Netzwerk-Interception

Mit Playwright kannst du HTTP-Anfragen abfangen und manipulieren, bevor sie den Server erreichen oder nachdem sie empfangen wurden. Das ermöglicht z. B.:

Beispiel:

await page.route('**/api/user', route => {
  route.fulfill({ status: 200, body: JSON.stringify({ name: 'Testuser' }) });
});

Screenshot

Playwright kann jederzeit einen Screenshot vom aktuellen Zustand der Seite aufnehmen – z. B. zur Fehlerdokumentation, zur visuellen Regression oder einfach als Debugging-Hilfe. Das ist besonders nützlich bei CI-Testläufen, wenn ein Test fehlschlägt.

Beispiel:

await page.screenshot({ path: 'screenshot.png', fullPage: true });

Tracing

Das Tracing-System von Playwright erstellt eine vollständige Aufzeichnung eines Testlaufs. Die generierte Datei (trace.zip) kann mit dem Trace Viewer analysiert werden. Dieser zeigt:

Der Trace Viewer eignet sich ideal zum Debuggen, wenn Tests unerwartet fehlschlagen oder das Timing von UI-Interaktionen unklar ist.

Verwendung:

npx playwright test --trace on
npx playwright show-trace trace.zip

Das Tool ist interaktiv und CI-fähig – es gehört zu den zentralen Debugging-Funktionen von Playwright.

HTML-Report

Playwright enthält standardmäßig einen HTML-Reporter, der nach einem Testlauf einen interaktiven Bericht erzeugen kann.

Verwendung:

npx playwright test --reporter=html
npx playwright show-report

Dabei entsteht ein Verzeichnis playwright-report/, in dem die Testergebnisse als durchklickbarer HTML-Bericht gespeichert werden. Der Report enthält:

Hinweis: Reporter lassen sich auch dauerhaft in playwright.config.ts setzen:

reporter: ['list', 'html']

Der HTML-Report eignet sich besonders gut für Reviews, Testprotokolle oder zur Weitergabe an Stakeholder.

Das Tracing-System von Playwright erstellt eine vollständige Aufzeichnung eines Testlaufs. Die generierte Datei (trace.zip) kann mit dem Trace Viewer analysiert werden. Dieser zeigt:

Der Trace Viewer eignet sich ideal zum Debuggen, wenn Tests unerwartet fehlschlagen oder das Timing von UI-Interaktionen unklar ist.

Verwendung:

npx playwright test --trace on
npx playwright show-trace trace.zip

Das Tool ist interaktiv und CI-fähig – es gehört zu den zentralen Debugging-Funktionen von Playwright.

Das Tracing-System von Playwright erstellt einen kompletten „Film“ eines fehlgeschlagenen Testlaufs: Es enthält Informationen über:

Diese Daten können im Playwright Trace Viewer visuell nachvollzogen werden – ideal zum Debuggen komplexer Fehler in CI/CD.

npx playwright test --trace on
npx playwright show-trace trace.zip

Debugging

Zusätzlich zum Tracing bietet Playwright u. a.:

Beispiel:

await page.pause(); // öffnet Debugger-Fenster mit DOM-Explorer

Integration in moderne Frameworks

Ein großer Pluspunkt ist die nahtlose Integration in moderne Toolchains. Bei der Installation eines SvelteKit-Projekts wird Playwright beispielsweise direkt mit angeboten. Es ist kein manueller Konfigurationsaufwand nötig.

Typische Teststruktur

Playwright kann Tests in mehreren Browsern ausführen – etwa in Chromium, Firefox oder WebKit. Wird in der playwright.config.ts jedoch kein projects-Abschnitt definiert, wie z. B. im SvelteKit-Starter, verwendet Playwright standardmäßig nur Chromium. Das reicht für viele Szenarien – schränkt aber die Cross-Browser-Testbarkeit ein.

Möchte man Tests zusätzlich in Firefox und WebKit durchführen, lässt sich die Konfiguration um projects erweitern:

projects: [
  { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  { name: 'firefox',  use: { ...devices['Desktop Firefox'] } },
  { name: 'webkit',   use: { ...devices['Desktop Safari'] } },
]

Playwright führt die Tests dann automatisch für alle angegebenen Browser durch – entweder nacheinander oder parallel, je nach Konfiguration. So lassen sich UI-Komponenten und Workflows direkt in allen wichtigen Rendering-Engines verifizieren.

Playwright führt die Tests dann automatisch für alle angegebenen Browser durch – entweder nacheinander oder parallel, je nach Konfiguration. So lassen sich UI-Komponenten und Workflows direkt in allen wichtigen Rendering-Engines verifizieren.

Playwright-Konfigurationen werden in der Datei playwright.config.ts definiert. Besonders praktisch ist dabei die Möglichkeit, den lokalen Server automatisch zu starten, bevor die Tests ausgeführt werden:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  webServer: {
    command: 'npm run build && npm run preview',
    port: 4173
  },
  testDir: 'e2e'
});

Diese automatische Startlogik ist besonders hilfreich für CI/CD, da kein separater Serverlauf erforderlich ist. Wer möchte, kann hier auch eigene Kommandos oder Ports verwenden – etwa um eine andere Umgebung zu testen oder eine API-Instanz parallel zu starten.

Playwright sucht standardmäßig in dem Ordner nach Tests, in dem sich deine playwright.config.ts befindet. Zudem erkennt es von sich aus alle Dateien mit den Endungen .spec.ts, .test.ts, .spec.js, .test.js.

Viele Framework-Vorlagen – z. B. SvelteKit – legen hierfür das Verzeichnis e2e/ an. Dies ist aber keine Vorgabe seitens Playwright, sondern eine Empfehlung, um Frontend- und End-to-End-Tests (E2E) strukturiert zu trennen.

Du kannst stattdessen auch beliebige andere Verzeichnisse nutzen (z. B. tests/, ui-tests/), solange sie sich im selben Verzeichnis wie playwright.config.ts befinden – oder du testDir in der Konfiguration entsprechend anpasst.

Nach dem Setup legt Playwright ein e2e/-Verzeichnis an (z. B. durch SvelteKit). Ein einfacher Test könnte so aussehen:

test('zeigt ein leeres Board mit 6x7 Zellen', async ({ page }) => {
  await page.goto('/');
  const cells = await page.locator('[data-test^=cell-]');
  await expect(cells).toHaveCount(6 * 7);
});

Häufig verwendete Befehle:

Nach dem Setup legt Playwright ein e2e/-Verzeichnis an. Ein einfacher Test könnte so aussehen:

test('zeigt ein leeres Board mit 6x7 Zellen', async ({ page }) => {
  await page.goto('/');
  const cells = await page.locator('[data-test^=cell-]');
  await expect(cells).toHaveCount(6 * 7);
});

Häufig verwendete Befehle:

Vergleich: Playwright, Cypress, Selenium

Merkmal Playwright Cypress Selenium
Ausführungskontext Außerhalb des Browsers über native DevTools-Protokolle Im Browser Extern via WebDriver
Sprachen JS/TS, Python, C#, Java Nur JS/TS Viele (Java, Python, etc.)
Browser-Support Chromium, Firefox, WebKit Chromium-basiert, Firefox (beta) Alle, inkl. IE
Multi-Tab, Multi-Window Voll unterstützt Eingeschränkt Möglich, aber komplex
Netzwerk-Interception Einfach via page.route() Eingeschränkt Aufwendig
Debugging Trace Viewer, Screenshots, CLI Zeitreise im Browser, GUI Schwerfällig
Setup-Aufwand Minimal (bei modernen Frameworks) Mittel Hoch

Geeignete Einsatzzwecke

Playwright eignet sich besonders für:

Weniger geeignet ist Playwright für klassische Unit-Tests oder Alt-Systeme mit Internet Explorer.

Erweiterte Konzepte & Best Practices

1. Locator-Strategien

Robuste Selektoren sind entscheidend:

2. Teststruktur

3. Parallelisierung & Stabilität

Playwright führt Tests standardmäßig parallel aus, um die Laufzeit zu optimieren – lokal ebenso wie in CI/CD. Das bringt große Vorteile, erfordert aber, dass die Tests entsprechend gestaltet sind.

Grundprinzip:

Schreibe Tests so, als würden sie gleichzeitig laufen.

Das bedeutet:

Typisches Problem: Zwei Tests nutzen denselben Nutzer oder Datensatz – je nach Reihenfolge oder Timing schlägt einer davon fehl. Das wirkt dann wie ein „flaky test“ – ist aber ein Architekturproblem.

Hilfreiche Optionen in der Konfiguration oder beim Aufruf:

Fazit: Parallele Tests sparen Zeit – aber nur, wenn sie wirklich unabhängig voneinander sind. Genau das sollte beim Schreiben konsequent beachtet werden.

4. Netzwerkinterception & Mocking

Revision #4
Created 11 June 2025 00:04:25 by Marius Klein
Updated 11 June 2025 08:53:52 by Marius Klein