E2E test tools, sorted by the one thing every roundup skips

Three families. Open-source coded frameworks: Playwright, Cypress, Selenium, WebdriverIO, and Puppeteer. Managed and record-and-replay services: QA Wolf, Mabl, Testim, testRigor, and Momentic. And AI agent layers that generate framework code, where Assrt sits. The first family is free and gives you total control at the price of writing and maintaining every selector. The second outsources maintenance but stores your tests in a vendor account and charges by test count. The third reads the live page and writes standard Playwright you keep.

Pick by how the tool locates elements, because that decides who pays the maintenance bill. If you want full control and have the engineering time to fix selectors, a coded framework like Playwright is the default. If you have budget and want maintenance off your plate, a managed service does that for a price that scales with test count. If you want the tests written for you but still want to own and run standard Playwright code in your own CI, an AI agent layer like Assrt fits: it generates the framework code rather than a proprietary format.

Because the feature matrix is interchangeable. Every serious tool already does parallel browsers, headless mode, screenshots, retries, and CI integration. What is not interchangeable is what breaks your suite. A test fails for one of a few reasons, and the most common one in practice is that the element it was pinned to moved or got renamed. A tool that stores a selector inherits that failure mode. A tool that re-resolves the page on every run does not have a stored selector to break.

Its agent calls a snapshot tool first to get the accessibility tree, where each actionable element carries a ref like ref="e5". It acts on that ref, then snapshots again after every action to see the updated page. If a ref goes stale, the recovery is another snapshot, not a fallback locator from a database. This is spelled out in the Selector Strategy and Error Recovery sections of assrt-mcp/src/core/agent.ts (lines 215 to 227). The agent exposes only ten tools: navigate, snapshot, click, type_text, scroll, evaluate, create_temp_email, wait_for_verification_code, assert, and complete_scenario.

It depends on the output. Managed record-and-replay services and tools built on a proprietary YAML or scenario format keep the test inside their system, so leaving means rebuilding. Assrt's output is a standard Playwright file. You commit it, run it in any CI, and if you stop using Assrt the tests keep running because they are plain Playwright. That is the practical meaning of zero vendor lock-in: your exit cost is whatever it costs to keep running code you already own.

Most coded suites stub auth or inject a session because driving a real login with a one-time code is fiddly. Assrt's agent has two tools for exactly this: create_temp_email gets a disposable inbox, and wait_for_verification_code reads the OTP back. For the common split-digit OTP input it pastes all digits at once with a fixed clipboard-event snippet hard-coded at agent.ts:237, rather than typing into each single-character field, which often misfires. So flows behind a sign-up gate are testable end to end, not skipped.

No, it is a layer on top of it. Assrt wraps @playwright/mcp and runs each test case through an LLM agent (Claude Haiku by default) that drives the browser with Playwright's own tools. The output is Playwright. Think of it as the part that writes and maintains the tests, while Playwright is still the engine that runs them. If you already love writing Playwright by hand, Assrt is the thing that handles the tedious first draft and the re-resolution when the UI shifts.