mcpField
V
verify

verify

github.com/e2e-incTesting & quality13.8k288 installsUpdated today
Repository

About verify

verify is a skill for validating changes to an end-to-end testing framework by running its built CLI, testbeds, benchmarks, and MCP tools as users would. It emphasizes reproducible evidence from real web and mobile test surfaces rather than relying only on unit tests.

Key features

  1. 01Run built CLI tests against deterministic apps
  2. 02Verify web behavior in Chromium
  3. 03Test mobile apps on simulators or emulators
  4. 04Replay agent benchmark recordings
  5. 05Inspect MCP tools on a testbed

Use cases

  1. 01Check CLI output and written reports after a change
  2. 02Verify locators against real web pages
  3. 03Replay agent tests after prompt or trace changes
  4. 04Test e2e MCP tools through a live session

MCP support

The skill describes using the e2e MCP server registered on the testbed. It covers opening sessions and calling observation, locator, screenshot, and action tools.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/e2e-inc/e2e --skill verify

After installing, type/verifyin Claude Code to confirm it loaded.

Details

From the project README

Verify

Every change ships with evidence from the real thing. Unit tests passing is not evidence that the CLI prints the right line, a locator finds the node on a real page, or an agent step replays. The testbed and the benchmarks are the app here: they consume the built packages the way a user does. Use this skill in the loop, not only at the end: change, build, run, look, repeat.

Setup

pnpm install --frozen-lockfile
pnpm --filter @e2e-dev/web exec playwright-core install chromium
pnpm build                    # every consumer below runs dist; rebuild after each change

A stale dist is the most common false result. Rebuild before trusting any run, and after switching branches.

Pick the surface

ChangeRunProves
Runner, collect, locator, config, sessions, CLI flagsthe testbed suite, or the file covering itThe built CLI end to end on a deterministic app
Reporters (list, json, markdown, junit)the testbed file plus test:stressThe printed and written output, hostile titles included
@e2e-dev/webthe testbed file, then the web benchmark's tests/Real Chromium on plain and hard surfaces
Agent (src/agent/), prompts, trace cachethe web benchmark's tests-agent/ replay, then --no-cache --ai-traceReplay still hits, and the live agent still reaches the goal
@e2e-dev/mobilethe mobile benchmark on a simulator or emulatorReal devices; see apps/mobile-benchmark
e2e mcpthe e2e MCP server on the testbedThe tools as a coding agent sees them
e2e init, packaging, the skillpacked tarballs in a scratch project under /tmpWhat a new user gets from npm
Docs pagespnpm docs:checkLinks, anchors, examples, package manager tabs, and logos
@e2e-dev/githubthe PR's own e2e-github commentsThe comment a user's PR gets

Commands (run from the app directory; call the CLI directly, since pnpm run <script> -- --flag forwards the -- and the CLI reads the flag as a file):

cd apps/testbed && node node_modules/e2e/dist/cli/bin.js run tests/todos.e2e.ts
cd apps/web-benchmark && pnpm run build     # the Next.js app, once per scenario change
cd apps/web-benchmark && node node_modules/e2e/dist/cli/bin.js run tests/<scenario>.e2e.ts
cd apps/web-benchmark && node node_modules/e2e/dist/cli/bin.js run --config e2e.agent.config.ts
pnpm test:testbed && pnpm test:web-benchmark          # the whole gate, as CI runs it
pnpm --filter @e2e-dev/testbed test:scroll            # scroll_to by text, scripted; its own CI step

Add a deterministic test next to the behavior when it must stay proven: a testbed page plus test for a runner feature, a benchmark scenario for a hard surface (keep scenario diffs minimal, never fix a planted bug). Tests follow skills/e2e, the consumer skill; this repo is its first consumer.

Agentic runs need AI_GATEWAY_API_KEY. The benchmark agent suites replay their committed recordings and call the model only for a step with none, as CI does; a step that spends a model call there means its recording went stale. Go live with --no-cache --ai-trace only when the change is to the agent, and read the trace with unbox-ai (compare main against the branch), never by opening it. Re-recorded entries are committed in the same PR ("Committed recordings" in AGENTS.md).

The MCP server

.mcp.json registers e2e mcp on the testbed. open_session, then call {tool: "observe"}, locate, screenshot, and the action verbs. Pass config: "../web-benchmark/e2e.config.ts" to open_session for a benchmark. The server process runs the dist it started with: after a rebuild, restart it (/mcp in Claude Code) before verifying MCP or engine changes through it. Several sessions can be open at once (--max-sessions, default 4); pass the session id to every call and close_session when done.

Use it to write locators (locate prints the screen.* call), to look at a surface before testing it, to verify changes to the MCP tools themselves, and to record a video of what you drove when the engine records video (both web and mobile do): start_recording once the screen is set up, stop_recording for the file paths.

Drive it like a user

  • Run the built CLI, not a unit test harness. Read what it prints and what it writes (.e2e/report.json, the trace pages under .e2e/results/<test>/trace.md, and --reporter list,markdown for .e2e/summary.md).
  • Exercise the failure path too: a change to an error code, a timeout, or a policy refusal is verified by triggering it and reading the message a user gets.
  • Check the side effects: artifacts land where the docs say, and a filled secret stays out of every file under .e2e/ (grep -r the value).
  • APP_ALREADY_RUNNING means another checkout's run holds the app port. Wait for it or ask; never stop a process you did not start.
  • Mobile: follow apps/mobile-benchmark/README.md for devices. One run per device at a time.

Evidence

The PR must show it working (writing-pr). Report the surface, what you ran, and what you saw, with media:

  • Terminal output: paste the relevant lines of the CLI output as a fenced text block (ANSI stripped, paths trimmed). This is the primary evidence for runner, CLI, and reporter changes.
  • Video: --video (add --headed to watch it) records every attempt, on an engine that records video, to .e2e/results/<test>/attempt-<n>/video/: video.webm from @e2e-dev/web, video.mp4 from @e2e-dev/mobile. Attach it for engine, locator, and agent changes a viewer can see.
  • Stills: cut a frame from the video (ffmpeg -ss <seconds> -i <video> -frames:v 1 after.png), or screenshot the docs page.
  • Bug fixes, main vs branch: write the regression test first and run it while the checkout still matches main, so the failure is captured. Already changed the code? Build main beside it: git worktree add /tmp/e2e-main origin/main, then pnpm install --frozen-lockfile && pnpm build there and run the same command in both.
  • Upload: gh pr create|edit --body-file body.md --attach ./after.png --attach ./video.webm (gh 2.99+) uploads each file, rewrites markdown image paths in the body, and appends videos as players. With an older gh, drag the files into the PR in the browser, or say the media is local and why.

If something could not be verified, say so and name the blocker. A confident claim without evidence is worse than "inconclusive".

Cleanup

e2e run stops the apps it started. close_session stops the MCP session's. Remove a /tmp/e2e-main worktree with git worktree remove when done.

Comments

Markdown supported