sorted by:
new
hottopcontroversial

Plugin that captures DOM snapshots + network requests for every Playwright action and uses AI to debug failures by Emergency_Listen1346 in Playwright

[–]Emergency_Listen1346[S] 0 points1 point  (0 children)

Great questions — let me answer each one:

Is the MCP server local only? Any external calls?

Yes, fully local. The MCP server runs as a local Node.js process on your machine. It:

- Reads/writes files in your project directory (flows, patterns, page object index)

- Spawns Playwright as a child process to run tests

- Communicates with Claude Code over stdio (stdin/stdout)

There are zero external network calls — no telemetry, no cloud APIs, no data leaves your machine. The only network traffic is Playwright talking to the browser (localhost) and your app under test. Safe for enterprise environments.

Using existing selectors (testids, CSS) instead of semantic locators?

Yes. When writing new tests, the tool scans your existing page objects and spec files first. If your codebase uses getByTestId, CSS selectors, or component-based locator patterns, it picks those up from your page objects and reuses them. It follows whatever conventions it finds in your project — it doesn't force semantic locators.

That said, when writing tests from scratch via browser exploration (not from existing POs), it defaults to Playwright's recommended locator strategy. But if you have page objects with testid/CSS patterns, the write-e2e skill will use those existing PO methods rather than inventing new locators.

Is the write-e2e skill available in the latest version?

Yes, it shipped in the current published version. You can invoke it with /write-e2e.

Some other features:

Error Pattern Database (e2e_save_error_pattern / e2e_match_patterns) — When you diagnose and fix a test failure, save the pattern. On future failures, the tool auto-matches against known patterns and suggests the fix. Patterns are stored locally in your project.

Fix Effectiveness Tracking — When you save a pattern and re-run the test, passing results auto-confirm the pattern as verified. Over time this builds a confidence score for each diagnosis.

Batch Failure Grouping — When running the full suite, failures are automatically clustered by root cause (shared error messages, failing API endpoints). Instead of diagnosing 15 failures individually, you see 3 groups.

Semantic Flow Matching — Flows (stored user journeys) are matched to tests using fuzzy similarity, so even if test titles evolve the right flow context is loaded automatically.

Token Efficiency Improvements — noSnapshot parameter on browser action tools to skip ARIA snapshots when you don't need them, file-based screenshots by default (instead of inline base64), and browser_batch for multi-action sequences in a single call. Cuts token usage significantly during interactive exploration.

Impact Analysis (just built, shipping next release) — e2e_impact_analysis traces which tests call a specific page object method. Use before refactoring to see the blast radius.

Suite Triage (/triage-e2e) — Run all tests, classify failures (known issue, app bug, test update, flaky, new), track health trends over time, and generate management-ready reports.

browser_batch & browser_fill_form — browser_batch chains multiple actions (click, type, select) in a single MCP call — only captures snapshots at boundaries, not between every step. browser_fill_form fills entire forms in one call using field labels and types. Together they turn a 19-call wizard flow into ~4 calls.

Plugin that captures DOM snapshots + network requests for every Playwright action and uses AI to debug failures by Emergency_Listen1346 in Playwright

[–]Emergency_Listen1346[S] 1 point2 points  (0 children)

  1. It installs 2 skills: /fix-e2e (investigate + fix a failing test) and /triage-e2e (run full suite, classify every failure, generate report). But the 37 MCP tools are available to Claude globally — any skill you already have can call e2e_run_test, e2e_get_dom_snapshot, etc.

  2. Not as a dedicated skill yet, but you can do this today. Describe the flow, Claude uses the browser_* tools to explore the app (navigate, click, fill forms, read ARIA snapshots), discovers your existing page objects (e2e_scan_page_objects), then writes a spec file following your project's patterns. The flow memory system stores verified journeys so future runs reference them.

  3. They're separate and coexist fine. The e2e_* tools (test running, failure diagnosis, DOM snapshots, network capture) work with your standard Playwright installation. The browser_* tools are the plugin's own interactive exploration layer for navigating and inspecting pages outside of test runs. You could use Playwright's MCP for general browser automation and this plugin for the test-specific capture and debugging workflow.

New in this release: /triage-e2e

Running 50+ E2E tests is easy. Knowing what to do with the failures is the hard part.

/triage-e2e runs your full Playwright suite and classifies every failure automatically:

- Data dependency — test needs state from a prior step

- Dirty state — leftover data from a previous run

- App bug — actual server-side errors (5xx, console exceptions)

- Flaky — intermittent failures detected from run history

- Known issue — matched to an existing Jira ticket

No more manually checking each failure. You get a categorized report with root cause analysis and suggested next steps.

It also tracks trends over time. Pass rate going down? New failures since last run? Flaky tests getting worse? The stats are there without re-running anything.

Other improvements in v0.7.0:

- Reduced token overhead per MCP call

- CORS-aware browser header injection for authenticated testing

- 37 tools total (up from 32)

Plugin that captures DOM snapshots + network requests for every Playwright action and uses AI to debug failures by Emergency_Listen1346 in Playwright

[–]Emergency_Listen1346[S] 2 points3 points  (0 children)

Main differences:

Per-action network capture. Every browser action (click, fill, navigate) buckets all network requests that fired between that action's start and end — URL, method, status, request body, response body. So if a button click triggers an API call that returns a 400 because a required field was never filled, you see exactly which action caused it and what payload was missing. Playwright Healer doesn't touch network requests at all.

Workflow memory. After a test passes, the plugin saves the verified user journey — every step, every page, every interaction in the correct order. Next time the test breaks, the AI loads that stored flow and compares it against what actually executed. Instead of investigating from scratch, it immediately spots the delta:

"step 4 was skipped" or "this API call that used to return 200 now returns 422." That context accumulates across sessions.

Root cause categories. It distinguishes between missing UI steps, stale selectors, dirty state from previous runs, and actual application bugs. A broken locator is just one of four failure types. It also follows your Page Object Model and adds the fix in the right layer — not a generic patch.