Playwright: eine Browser-API für Tests, Skripte und Agents

Playwright ist Microsofts Browser-Automatisierung und inzwischen drei Produkte in einem Repository: ein Test-Runner, eine Scripting-Bibliothek und eine Agent-Fläche aus MCP-Server und Kommandozeilenwerkzeug. Es steht unter Apache-2.0, es gibt keine bezahlte Edition, und es bleibt die komfortabelste API dieser Kategorie. Die Position dieses Tests: der Standard für neue End-to-End-Arbeit — und die Agent-Flächen sind der Grund, eine bestehende Suite noch einmal anzusehen.

Es konkurriert mit Selenium, Cypress und Puppeteer und zunehmend mit handgeschriebenen Scraping- und QA-Skripten, weil dasselbe page-Objekt jetzt einen Test in der CI, einen nächtlichen Report und ein LLM bedient, das den Browser über Accessibility-Snapshots steuert. Im Kern braucht keines davon ein Modell: die Agent-Werkzeuge liegen obenauf und lassen sich ignorieren — deshalb setzen Teams es zuerst als Testwerkzeug ein und entdecken die Agent-Ebene später.

Was es ist

Das Projekt liefert Browser-Automatisierung für Chromium, Firefox und WebKit unter Windows, Linux und macOS, lokal oder in der CI, im Hintergrund oder sichtbar, mit nativer Mobil-Emulation für Android Chrome und Mobile Safari. Die aktuelle Linie ist 1.63, veröffentlicht im September 2026, und die Browser-Binaries sind an diese Version gebunden.

• Apache-2.0 ohne bezahlte Edition; das npm-Paket setzt Node 20 oder neuer voraus.
• Eine API in vier Sprachen: JavaScript und TypeScript, Python, Java und .NET.
• Ein Test-Runner mit Auto-Waiting, Web-First-Assertions, Fixtures, parallelen Projekten, Sharding, Retries und HTML-Report.
• Browser-Kontexte geben jedem Test ein frisches Profil, damit Anmeldezustand ein Fixture und kein globales Geteiltes ist.
• Werkzeuge um den Lauf: Codegen, UI-Modus, Trace-Viewer, Netzwerk-Mocking, Clock-Steuerung und Aria-Snapshots.
• Offizielle Container-Bilder je Release, wodurch die CI-Browser identisch zu den lokalen bleiben.
• Drei Agent-Flächen: ein MCP-Server, eine CLI mit installierbaren Skills sowie Planner-, Generator- und Healer-Testagents.

Wie es funktioniert

Der Treiber spricht jeden Browser über eigenes Protokoll — gepatchte Chromium- und Firefox-Builds plus ein gepatchtes WebKit —, und genau dadurch kann eine API dieselben Fähigkeiten auf allen drei Engines bieten statt des kleinsten gemeinsamen Nenners. Lokatoren werden zum Zeitpunkt der Aktion aufgelöst, und jede Aktion wartet, bis das Element bedienbar ist; der übliche Fix für einen flüchtigen Test ist damit eine Assertion statt eines Sleeps.

Über dem Treiber sitzt der Runner, wo der eigentliche Wert entsteht: eine Konfigurationsdatei deklariert die Projekte — Browser, Viewports, Zugangsdaten —, Tests werden auf Worker verteilt, Sharding teilt sie auf Maschinen auf, und jeder Fehler trägt einen Trace, Schritt für Schritt abspielbar. Dieser Trace macht auch eine assistierte Diagnose praktikabel, weil er strukturierte Daten sind statt ein Screenshot eines Stack-Traces.

Erste Schritte

Ein Scaffold, ein Install, ein Lauf: npm init playwright@latest schreibt Konfiguration und erste Spec, npx playwright install --with-deps holt die versionsgebundenen Browser-Binaries samt Systembibliotheken, und npx playwright test läuft im Hintergrund und parallel über alle drei Engines.

import { test, expect, devices } from '@playwright/test';

test('order confirmation shows a number', async ({ page }) => {
  await page.goto('/checkout');
  await page.getByLabel('Email').fill('qa@example.com');
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByRole('status')).toContainText(/Order WS-\d+/);
});

test.describe('phone', () => {
  test.use({ ...devices['iPhone 15'] });
  test('checkout renders on a phone viewport', async ({ page }) => {
    await page.goto('/checkout');
    await expect(page.getByRole('heading', { name: 'Checkout' })).toBeVisible();
  });
});

Was altern lässt, ist nicht der Runner, sondern die Selektoren. Die Empfehlung des Projekts: Rollen- und Label-Lokatoren bevorzugen, Assertions web-first halten, damit sie bis zum Timeout neu prüfen statt einmal zu sampeln, und bei Fehler den Trace öffnen statt aus dem Stack zu raten.

Agents am Steuer

Das ist der Teil, der den Status des Werkzeugs verändert hat. Playwright ist inzwischen ein Standardweg, wie ein Sprachmodell einen Browser bedient, und das Projekt liefert drei Wege dorthin, alle aus erster Hand.

# MCP server: structured tool calls, accessibility snapshots with element refs
{
  "mcpServers": {
    "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }
  }
}

# CLI: shell commands for a coding agent, headless by default
npm install -g @playwright/cli
playwright-cli open https://example.com
playwright-cli snapshot
playwright-cli click e5

# Test agents: planner, generator and healer, installed into the repo
npx playwright init-agents --loop=vscode

• Der MCP-Server liefert Accessibility-Snapshots: jedes Element trägt ein Ref wie e5, das Modell klickt eine Referenz statt Koordinaten zu raten, und kein Vision-Modell ist nötig. Die Dokumentation listet 70+ Werkzeuge, Netzwerk-Mocking, Storage, Tracing und Video hinter Capability-Flags.
• Die CLI ist der token-sparende Weg: knappe Ausgabe, ein persistenter Daemon, damit Befehle keinen Browser-Start bezahlen, Skills bei Bedarf und Sessions, die Zustand zwischen Befehlen behalten.
• Playwright-Testagents — Planner, Generator und Healer — schreiben einen Markdown-Testplan, übersetzen ihn in Specs und patchen fehlgeschlagene Tests durch erneutes Abspielen und Prüfen der Seite; npx playwright init-agents installiert die Definitionen für VS Code, Claude Code, Codex und OpenCode.
• Die Dokumentation benennt den Tausch direkt: MCP passt zu spezialisierten agentic Loops und explorativer Automatisierung, die CLI zu Coding-Agents mit großen Codebasen, und die CLI startet im Hintergrund, während MCP einen sichtbaren Browser öffnet.

Die Token-Ökonomie entscheidet häufiger als die Features. Ein MCP-Umschlag legt bei jedem Schritt Tool-Schemas und einen frischen Snapshot in den Kontext; ein CLI-Befehl liefert den Pfad zu einer YAML-Snapshot-Datei und eine Zeile Status. Für einen langlebigen Agent, der nur durch einen Ablauf klicken muss, ist das der Unterschied zwischen einer Sitzung, die in den Kontext passt, und einer, die es nicht tut.

Screenshots gibt es weiterhin — ein Tool-Aufruf, und der Vision-Modus setzt die Maus auf Koordinaten —, sie kosten aber Tokens pro Pixel und bringen genau die Mehrdeutigkeit zurück, die das Snapshot-Design entfernt hat. Der Accessibility-Baum ist eine Zusammenfassung, auf die das Modell handeln kann; ein Screenshot ist Beleg, das es deuten muss.

Preise

Das Framework kostet nichts, es gibt keine Pro-Edition, keine Sitzplätze und keine Nutzungsverrechnung. Kosten entstehen an drei Stellen: CI-Minuten, die die Suite verbrennt, die Arbeitszeit, die sie grün hält, und — nur wenn ein verwaltetes Grid gewünscht ist — Microsofts Cloud aus erster Hand.

• Framework: kostenlos unter Apache-2.0, unbegrenzte Projekte und Tests, keine zu verlängernde Lizenz.
• Playwright Workspaces in Azure App Testing: nutzungsbasiert pro Testminute, sekundengenau abgerechnet, mit einem 30-Tage-Test inklusive 100 Minuten; darüber hinaus wechselt der Workspace in den bezahlten Tarif, und die veröffentlichten Sätze hängen von der Region ab.
• Fremd-Grids wie BrowserStack und Sauce Labs rechnen pro paralleler Sitzung oder Abo ab und sind nur für echte Geräte, eine breitere Browser-Matrix oder Compliance nötig.
• Die größte Position ist nie die Lizenz: das Aufräumen flüchtiger Tests und die Pflege von Selektoren sind die wiederkehrenden Kosten, und kein Plan deckt sie ab.

Weil der Runner kostenlos ist, geht es bei der Migration meist um Zeit statt um Budget. Ein bestehender Suite-Stack bedeutet umgeschriebene Selektoren, Fixtures und Custom Commands, und die Amortisation kommt mit dem zweiten Wartungsmonat, nicht mit dem ersten grünen Build.

Wo es quietscht

Die Schwächen sind bekannt und größtenteils akzeptiert. Browser-Binaries sind pro Release gebunden, ein Upgrade ist also eine geplante Aufgabe, die die CI-Images mitzieht. Die Breite des Runners ist viel Fläche, bevor ein Team etwas von Sharding und Traces hat. WebKit ist hier ein gepatchtes Build statt Safari selbst, ein Apple-spezifischer Defekt kann also spät auftauchen. Und die CLI- und MCP-Schichten sind neu genug, dass ihre Befehlssätze zwischen Minor-Releases wandern.

Das ehrliche Vergleichsziel ist der Umfang, nicht die Qualität. Selenium bleibt die Antwort, wenn ein Vertrag WebDriver oder eine Device-Cloud verlangt; Cypress liegt bequem für Teams, die in seinen Component-Test-Runner investiert sind; Puppeteer ist eine Bibliothek, kein Framework, und die richtige Größe für ein Skript. Playwright behauptet, eines dieser vier Werkzeuge zu sein — und die Wartungskosten dieser Behauptung sind die Browser-Matrix, die nun in der CI läuft.

Fazit

Playwright ist der stärkste Standard der Browser-Automatisierung, und die interessante Frage ist nicht mehr, ob man es einführt, sondern welche seiner drei Flächen man wem aussetzt.

1. Für neue End-to-End-Arbeit einführen. Runner, Kontext-Isolation und Trace-Viewer zahlen sich ab dem zweiten Monat aus — genau dann, wenn ein dünneres Werkzeug teurer wird.
2. Einführen, wenn ein Agent den Browser führen muss. Refs und Rollen sind günstiger und deterministischer als Pixel, und das Projekt pflegt MCP und CLI selbst, statt sie der Community zu überlassen.
3. Den Upgrade-Rhythmus einplanen: eine Release-Linie, die alle paar Wochen neue Browser-Binaries zieht, bedeutet, dass Lockfile, Image und Browser zusammen bewegt werden oder gar nicht.
4. Selenium behalten, wo WebDriver oder eine Device-Cloud vertraglich ist, und eine grüne Cypress-Suite nicht umschreiben, nur weil die API woanders schöner ist.
5. Die Testagents nicht als Review behandeln. Der Healer darf einen Test überspringen, den er für defekt hält — sinnvoll als Standard, schlecht, wenn es unbemerkt passiert.

Der Browser ist nicht mehr nur das, was getestet wird; er ist auch die Schnittstelle, die ein Agent bedient. Werkzeuge, die ihn als strukturierten Zustand zeigen — Rollen, Refs, Text — altern besser als solche, die ihn als Pixel zeigen.

Quellen

1. Playwright-Dokumentation: Installation
2. Playwright MCP: Einführung
3. Playwright CLI: Einführung
4. Playwright Test Agents
5. npm-Paketmetadaten für @playwright/test
6. Microsoft Learn: Testversion von Playwright Workspaces
7. Azure App Testing: Preise