The best e2e testing tools, ranked by time to first green check. Not feature count.

Features are fungible across the top ten entries on any guide. Playwright, Cypress, WebdriverIO, TestCafe, Nightwatch, and Puppeteer all ship parallel browsers, auto-waiting, screenshots, and CI integration; the list differences are stylistic. The number that is not fungible, and almost never written down, is the wall-clock time between running the install command and watching the first green check land in your terminal. That gap is where brand-new suites quietly die. A team that spends four hours wiring up selectors and fixtures before the first pass usually does not come back on Monday. A team that sees a green check in the first fifteen minutes usually does. Ranking on this axis surfaces a tool category the feature matrices miss entirely: agent-driven runners that take a URL and produce executable cases. Assrt is in that category, and its plan tool accepts exactly one parameter.

The MCP tool is registered in assrt-mcp/src/mcp/server.ts at lines 768 through 774. The Zod schema has one required field, url (a string), and one optional model override. That is it. When a coding agent calls it, the server launches a Playwright browser, navigates to the URL, takes three screenshots at scroll offsets 0, 800, and 1600 pixels (lines 794 through 805), concatenates the accessibility trees, and sends the whole bundle to claude-haiku-4-5-20251001 under a prompt that asks for five to eight executable Case blocks in Markdown. The return value is a plan that assrt_test can run in the same session. No spec file. No selector authoring. No fixture setup. One URL in, a runnable plan out.

The candidate set that appears in almost every guide: Playwright, Cypress, Selenium, WebdriverIO, TestCafe, Nightwatch, Puppeteer, Robot Framework on the open-source side; Mabl, testRigor, Applitools, Katalon, Tricentis Tosca, ACCELQ, BrowserStack, LambdaTest on the commercial side. The lists argue about ordering and about a handful of newer AI-first platforms. They do not argue about whether the category includes MCP-driven agent runners, because most guides were written before that category existed. Assrt is one of the first entries in it, and the authoring input is genuinely smaller than the closest neighbour.

On a local dev server the typical path is: npx -y assrt-mcp (under a minute to pull and run), add the server to your Claude Code or Cursor config (a few seconds of JSON), then ask the assistant to call assrt_plan on a URL. The plan call itself takes roughly 20 to 40 seconds because it launches a browser and runs three screenshot rounds before asking Claude Haiku to produce the plan. Running the first Case through assrt_test is another 10 to 30 seconds depending on page complexity. The practical floor is around two minutes, and the practical ceiling for a first-time setup is around ten. Raw Playwright for the same app is closer to 45 minutes of spec-file and selector work before the first assertion fires. Selenium is the expensive extreme, often hitting two hours before a first green check on a fresh machine.

It is a tool in the same category but a different architectural tier. Under the hood it calls @playwright/mcp to drive a real Chromium over stdio, so every action (navigate, click, type_text, scroll, press_key, snapshot, wait, evaluate) is real Playwright. The execution engine is the same one Playwright users trust. What is different is the authoring layer: instead of writing page.click and selectors, you write a Markdown Case block in English, and the agent decides which tool call to make from the accessibility tree at runtime. The execution is real Playwright; the authoring is natural language; the storage is plain text. You get the reliability of the execution layer without paying the spec-file tax.

No. Every plan is saved to /tmp/assrt/scenario.md with a UUID. The agent writes its plan to disk before it runs. Re-running a saved plan is assrt_test with the scenarioId argument, and it executes the same Markdown text. The Markdown is also commit-ready for your repo. The selectors are re-resolved on every run against the live accessibility tree, which is what makes the approach tolerant of minor UI changes, but the plan itself is deterministic text that you can diff, grep, and PR-review the same way you review any other artifact.

Two answers. First, the plan is visible Markdown, not a black-box recording, so you can read the five to eight Case blocks the model produced and delete or edit anything that looks off. Second, if you run a plan and a case fails, call assrt_diagnose with the URL, the failing scenario, and the failure message. The server returns a four-section response: Root Cause, Analysis, Recommended Fix, and a literal Corrected Case block in the same grammar. You paste the correction over the failing case and re-run. The entire loop stays in plain text and stays on disk.

Because the longer the gap, the more likely the person running it decides the tool is the problem rather than their test strategy, and abandons the attempt before producing any evidence. A team that writes five specs in the first sitting and sees them pass develops a habit; a team that spends a full afternoon configuring a selectors file and a CI workflow and never sees a green check develops a grudge. The gap is a coordination problem disguised as a technical problem, and the tools that collapse it the fastest have an outsized effect on whether a suite ever actually gets to a thousand scenarios.

No. They are excellent execution engines and, in the hands of a seasoned QA team, they are still the right default for a mature suite. What this article argues is that the question 'what is the best tool' changes depending on the year-one cost. For a brand new team with no test suite yet, the tool that shortens install-to-first-pass wins; that tool is the one with a smaller authoring surface. For a team already five hundred scenarios in on Playwright, the tool that wins is Playwright. The two coexist. Many teams run both: Assrt for smoke cases a founder or PM writes, Playwright for the deeper suite a QA engineer maintains.

The MCP server, the agent, and the CLI are MIT-licensed and free. The only usage-based cost is the LLM API calls the agent makes to plan and interpret your scenarios; by default it uses claude-haiku-4-5-20251001 with your own Anthropic API key, and a typical plan-then-run loop costs cents, not dollars. There is an optional hosted dashboard at app.assrt.ai for sharing runs, which is free for individual use. You do not pay a seat fee, a parallelization fee, or a workspace fee to keep your tests private; they stay as Markdown files in your repo.