Playwright Autopilot

Nutzen Sie Selenium, Cypress oder WebDriverIO? E2Epilot bringt dieselbe KI-Triage-Engine in 6 Frameworks – einschließlich Selenium Java, SeleniumBase und mehr. Website: e2epilot.com | npm: @e2epilot/cli

Ein Claude Code-Plugin, das Playwright E2E-Tests autonom debuggt und repariert. Es führt Ihre Tests mit vollständiger Aktionserfassung aus – DOM-Snapshots, Netzwerkanfragen, Konsolenausgaben, Screenshots – untersucht dann Fehler wie ein erfahrener QA-Ingenieur und liefert die Korrektur aus.

https://github.com/user-attachments/assets/26f734a5-d05e-41c9-bc3f-2b58561c2ce0

Schnellstart

# Add the marketplace
/plugin marketplace add kaizen-yutani/playwright-autopilot

# Install the plugin
/plugin install kaizen-yutani/playwright-autopilot

Bitten Sie dann Claude, einen fehlschlagenden Test zu reparieren oder Ihre gesamte Suite zu triagieren:

/playwright-autopilot:fix-e2e tests/checkout.spec.ts
/playwright-autopilot:triage-e2e e2e

Oder beschreiben Sie einfach, was Sie benötigen – Claude verwendet die MCP-Tools automatisch:

Fix all failing e2e tests in the "e2e" project

Related MCP server: Browser Testing MCP Server

Was es tut

Jede Browser-Aktion während eines Testlaufs wird erfasst mit:

• Vorher/Nachher DOM-Snapshots – Aria-Baum der Seite vor und nach jedem Klick, Ausfüllen, Navigieren

• Netzwerkanfragen – URL, Methode, Status, Timing, Request/Response-Bodies

• Konsolenausgaben – Fehler, Warnungen, Protokolle, die mit der Aktion verknüpft sind, die sie erzeugt hat

• Screenshots – aufgenommen zum Zeitpunkt des Fehlers

Wenn ein Test fehlschlägt, rät Claude nicht – es liest den tatsächlichen Seitenstatus, prüft auf fehlgeschlagene API-Aufrufe und verfolgt die Ursache durch die Aktions-Timeline.

Funktionsweise

1. Capture Hook

Ein leichtgewichtiger CJS-Hook (captureHook.cjs) wird über NODE_OPTIONS --require in die Test-Worker-Prozesse von Playwright injiziert. Er führt ein Monkey-Patching von BrowserContext._initialize durch, um einen Instrumentierungs-Listener hinzuzufügen, der jede Browser-Aktion mit vollem Kontext erfasst. Es sind keine Änderungen am Quellcode von Playwright erforderlich – funktioniert mit jeder Playwright-Installation.

2. MCP-Tools

Das Plugin stellt 37 Tools über das Model Context Protocol bereit, die Claude bei Bedarf aufruft. Dies ist konzeptionsbedingt token-effizient – anstatt gesamte Traces in den Kontext zu laden, zieht Claude nur das, was es benötigt:

Testausführung & Debugging:

Interaktive Browser-Erkundung:

Die browser_*-Tools starten eine echte Chrome-Instanz und lassen Claude Ihre Anwendung interaktiv erkunden – Seiten navigieren, Elemente anklicken, Formulare ausfüllen und den Seitenstatus durch ARIA-Snapshots beobachten. Jede Interaktion gibt Timing, Netzwerkanfragen, DOM-Änderungen und einen aktualisierten Snapshot zurück. Nutzen Sie dies, um eine App zu verstehen, bevor Sie Tests schreiben, UI-Probleme visuell zu debuggen oder Korrekturen zu verifizieren.

3. Flow Memory

Nach dem Reparieren (oder Verifizieren) eines Tests speichert das Plugin den bestätigten Anwendungsablauf – die Sequenz von Benutzerinteraktionen, die den Happy Path bilden. Diese Abläufe bleiben in .e2e-flows.json bestehen und sammeln sich über Sitzungen hinweg an.

Wenn dieser Test das nächste Mal fehlschlägt, kennt Claude bereits den beabsichtigten Benutzerpfad und springt direkt zur Identifizierung dessen, was sich geändert hat. Der Agent wird mit der Zeit schneller.

4. Flaky-Erkennung

Zwei komplementäre Modi zur Identifizierung von Flaky-Tests:

retries: N — Führen Sie den Test N+1 Mal in separaten Playwright-Prozessen aus. Jeder Lauf erhält seine eigene runId mit vollständiger Aktionserfassung. Gibt ein Urteil zurück: FLAKY, CONSISTENT PASS oder CONSISTENT FAIL. Am besten zum Debuggen mit 2-3 Wiederholungen.

e2e_run_test(location: "tests/checkout.spec.ts:15", retries: 2)

repeatEach: N — Natives Playwright --repeat-each. Alle Iterationen in einem Prozess. Schneller Stresstest zur Bestätigung von Flakiness – verwenden Sie 30-100 für Sicherheit.

e2e_run_test(location: "tests/checkout.spec.ts:15", repeatEach: 40)

5. Evidence Bundles

e2e_get_evidence_bundle verpackt alle Fehlerbelege in eine einzige Antwort – Fehler, Schritte zur Reproduktion, Aktions-Timeline, fehlgeschlagene Netzwerkanfragen mit Bodies, Konsolenfehler, DOM-Snapshot und Screenshots. Ersetzt das separate Aufrufen von 6+ Tools.

Übergeben Sie outputFile: true, um eine Markdown-Datei in test-reports/ für Jira-Anhänge zu schreiben.

6. HTML-Berichte

Batch-Läufe (ohne location) generieren automatisch einen eigenständigen HTML-Bericht mit:

• Zusammenfassung der Bestehen/Fehlschlagen-Ergebnisse mit Status-Badges

• Einklappbare Abschnitte pro Test

• Aktions-Timelines, fehlgeschlagene Netzwerkanfragen, Konsolenfehler

• DOM-Snapshots an Fehlerpunkten

• Screenshots als eingebettete Base64-Bilder

Berichte werden in test-reports/report-<runId>.html geschrieben. Sie können e2e_generate_report auch manuell für jeden Lauf aufrufen.

7. Suite-Triage & Gesundheitsverfolgung

Führen Sie Ihre gesamte Suite aus, klassifizieren Sie jeden Fehler und erstellen Sie einen managementtauglichen Bericht:

/playwright-autopilot:triage-e2e e2e

Claude klassifiziert jeden Fehler als Bekanntes Problem, App-Fehler, Test-Update, Flaky oder Neuer Fehler – verknüpft Jira für bestehende Tickets, erstellt neue Tickets für App-Fehler mit Evidence Bundles und speichert den Triage-Lauf zur Trendverfolgung.

e2e_get_stats bietet ein Suite-Gesundheits-Dashboard – Trends der Erfolgsrate, nach Score sortierte Flaky-Tests, Aufschlüsselungen der Fehlerkategorien und neue Fehler – alles aus dem lokalen Verlauf, ohne Tests auszuführen.

9. Abdeckungsanalyse

e2e_suggest_tests scannt Ihr gesamtes Projekt, um Abdeckungslücken zu finden:

1. Nicht getestete Page-Objekt-Methoden – Methoden in .page.ts / .service.ts-Dateien, die von keiner Spec aufgerufen werden

2. Fehlende Ablaufvarianten – Abläufe mit Vorbedingungen (z. B. "kein Entwurf vorhanden"), denen eine Fortsetzungsvariante fehlt

3. Nicht abgedeckte Ablaufschritte – Aktionen, die in bestätigten Abläufen aufgeführt sind, die keine Spec ausführt

10. Architektur-Bewusstsein

Bevor eine Korrektur geschrieben wird, scannt das Plugin Ihr Projekt nach Page-Objekten, Service-Layern und Test-Fixtures. Es folgt Ihren bestehenden Mustern:

• Verwendet Ihre Page Object Model-Methoden, anstatt rohe Playwright-Aufrufe zu schreiben

• Respektiert Ihre Trennung von Business/Service-Layer

• Verwendet getByRole(), getByTestId(), Web-First-Assertions

• Erzeugt minimale Diffs – typischerweise ein oder zwei hinzugefügte Zeilen

Debugging-Philosophie

Das Plugin folgt einer strengen diagnostischen Methodik:

Denken Sie in Benutzerabläufen, nicht in Selektoren. Bevor Code angefasst wird, wird der beabsichtigte Benutzerpfad abgebildet. Wenn ein Schritt fehlt – ein Dropdown nie ausgewählt, ein Pflichtfeld nie ausgefüllt – findet es die bestehende Page-Objekt-Methode und fügt den Aufruf hinzu.

Vier Ursachenkategorien:

1. Fehlender Testschritt – der Test überspringt eine UI-Interaktion, die die App erfordert

2. Testcode-Fehler – falscher Selektor, veraltete Assertion, schlechte Testdaten

3. Anwendungsfehler – die App selbst ist defekt (gemeldet, nicht umgangen)

4. Verschmutzter Status – Überbleibsel von vorherigen Testläufen, die stören

Keine Hacks. Das Plugin wird niemals page.evaluate(), page.route(), page.addInitScript() oder irgendeine JavaScript-Injektion verwenden, um einen fehlschlagenden Test zu umgehen. Wenn die Korrektur diese erfordert, löst sie das falsche Problem.

Konfiguration

Multi-Projekt-Setup

Wenn sich Ihr Playwright-Projekt in einem anderen Verzeichnis befindet als dort, wo Claude Code ausgeführt wird, setzen Sie die Umgebungsvariable PW_PROJECT_DIR in .mcp.json:

{
  "mcpServers": {
    "playwright-autopilot": {
      "command": "node",
      "args": ["path/to/plugin/server/mcp-server.js"],
      "env": {
        "PW_PROJECT_DIR": "/path/to/your/playwright/project"
      }
    }
  }
}

Anforderungen

• Claude Code CLI

• Playwright Testprojekt

• Node.js 20+

Lizenz

MIT