You Do Not Need a Playwright Alternative. You Need to Stop Writing Playwright Tests by Hand.
Every "Playwright alternative" article recommends switching to Cypress, Selenium, or a $7,500/month AI SaaS. They all miss the point. Playwright is the best browser automation engine available. The problem is that writing and maintaining Playwright test code by hand takes more engineering time than the features those tests are supposed to protect. Assrt keeps Playwright as the engine and replaces the manual authoring with plain-text scenarios driven by an open-source AI agent.
“Assrt's AI agent executes 18 Playwright MCP tools at runtime from plain-text test plans. No selectors to write. No assertions to code. MIT licensed.”
@assrt-ai/assrt v0.4.1-beta.5, src/core/agent.ts
1. The Real Problem with Manual Playwright Testing
Playwright itself is excellent. It has the fastest browser automation, the best cross-browser support, and a clean API. The problem is everything you have to write around it.
A typical Playwright test for a login flow is 30 to 50 lines of TypeScript. It chains page.goto(), page.fill(), page.click(), and expect() calls with CSS selectors or test IDs that break every time the frontend team refactors a component. You spend time learning the Playwright API, debugging selector mismatches, handling race conditions with waitForSelector, and updating tests after every UI change.
The "alternatives" to this are not really alternatives. Cypress has the same selector problem. Selenium has the same maintenance burden, plus slower execution. Proprietary AI tools like Testim, QA Wolf, and Momentic solve the authoring problem but lock you into their cloud, their format, and their pricing ($2,500 to $7,500 per month or more).
What if you could keep Playwright's engine and just stop writing the test code?
2. How Assrt Replaces Manual Authoring
With Assrt, you write test scenarios as plain text using a #Case N: format:
#Case 1: Login with valid credentials
Navigate to the login page
Type "user@example.com" into the email field
Type "password123" into the password field
Click the Sign In button
Assert that the dashboard heading is visible
#Case 2: Login with wrong password
Navigate to the login page
Type "user@example.com" into the email field
Type "wrongpassword" into the password field
Click the Sign In button
Assert that an error message appearsThat is the entire test. No imports, no selectors, no page.locator() chains. The scenario parser in agent.ts splits this text on the #Case headers using the regex /(?:#?\s*(?:Scenario|Test|Case))\s*\d*[:.]/gi. Each case becomes an independent execution unit.
An AI agent (Claude Haiku by default, configurable) then reads the scenario text, inspects the page's accessibility tree via the snapshot tool, and decides which browser action to take. It clicks elements by accessibility description, not by CSS selector. It types into fields by reading what label they have, not by matching a test ID. When the UI changes, the agent adapts, because it reads the page the way a human does.
Each scenario is limited to 60 steps. If the agent cannot complete a case in 60 tool calls, something is wrong with the scenario or the application. This hard limit prevents runaway tests.
Try it in 30 seconds
npm install -g @assrt-ai/assrt, then run assrt run with your URL and test plan. No signup, no API key from Assrt, no cloud dependency.
Get Started →3. The 18 Tools the Agent Uses
The agent does not generate Playwright code files. Instead, it calls 18 Playwright MCP (Model Context Protocol) tools at runtime. Each tool is a function the LLM can invoke, defined with a JSON Schema for parameters. Here is what the agent has access to:
| Tool | Purpose |
|---|---|
| navigate | Go to a URL and wait for the page to load |
| snapshot | Read the full accessibility tree with element ref IDs |
| click | Click an element by description or ref ID |
| type_text | Clear a field and type new text |
| select_option | Choose a value from a dropdown |
| scroll | Scroll the page by a specified amount |
| press_key | Send a keyboard event (Enter, Escape, Tab) |
| wait | Pause for a duration or until text appears |
| screenshot | Capture the current viewport as a JPEG |
| evaluate | Run JavaScript in the page context |
| assert | Record a pass/fail assertion with evidence |
| complete_scenario | Signal that a test case is finished |
| suggest_improvement | Report a UX issue found during testing |
| http_request | Call an external API (webhooks, polling) |
| wait_for_stable | Wait until the DOM stops changing |
| create_temp_email | Generate a disposable email for signup testing |
| wait_for_verification_code | Poll a temp inbox for OTP codes |
| check_email_inbox | Read emails from the temp mailbox |
Notice the last three tools: create_temp_email, wait_for_verification_code, and check_email_inbox. These let the agent test full signup flows with email verification without any external service integration. In manual Playwright, email testing requires setting up Mailosaur, Ethereal, or a custom SMTP trap. With Assrt, you write "Sign up with a new email and verify the account" and the agent handles the rest.
4. Open Source Means You Own Everything
The npm package @assrt-ai/assrt (v0.4.1-beta.5) is MIT licensed. The entire agent, including the tool definitions, the scenario parser, and the system prompt, lives in src/core/agent.ts. You can:
- Read the system prompt to understand exactly why the agent chose a particular action when a test fails
- Add custom tools (a
check_databasetool, avalidate_pdftool) by appending objects to the TOOLS array - Swap the LLM from Claude to Gemini, or point it at any function-calling-capable model
- Self-host the CLI with no cloud dependency; the browser runs locally and test data stays on your machine
- Commit test scenarios to git as plain markdown files alongside your source code
Your test scenarios are plain text. They do not reference Assrt APIs, proprietary identifiers, or platform-specific syntax. If you stop using Assrt tomorrow, your test plans are still readable English descriptions of what your application should do. Zero vendor lock-in.
Compare this to proprietary alternatives: QA Wolf runs tests on their infrastructure at $7,500/month. Momentic uses a closed AI agent you cannot inspect, at around $2,500/month. Testim stores tests in their cloud format. With all of them, leaving means rewriting your tests from scratch.
5. Assrt vs. the Alternatives SERP Results Recommend
Search for "manual Playwright alternative" and you will find the same five tools in every article: Cypress, Selenium, Puppeteer, TestCafe, and WebDriverIO. Here is why none of them solve the actual problem:
| Dimension | Assrt | Traditional alternatives |
|---|---|---|
| Test format | Plain English, #Case N: markdown | TypeScript/JavaScript code with selectors |
| Selector maintenance | None (agent reads accessibility tree at runtime) | Manual updates on every UI change |
| Learning curve | Describe what to test in English | Learn library API, async patterns, CI config |
| Email/OTP testing | Built-in (3 dedicated tools) | Requires external service (Mailosaur, Ethereal, etc.) |
| Error recovery | Agent adapts dynamically (reads page, retries differently) | Hard-coded retry logic or test failure |
| Price | Free (MIT), pay for LLM API calls only | Free (open source) but high engineering time cost |
| Browser engine | Playwright Chromium (same engine, no switching) | Various (Cypress: Electron, Selenium: WebDriver, etc.) |
| Vendor lock-in | Zero (plain text tests, MIT code) | Low (open source) but API-specific test code |
The traditional alternatives solve the wrong problem. Switching from Playwright to Cypress does not eliminate selector maintenance. It just moves it to a different API. Switching to Selenium does not reduce the lines of test code you write. It increases them. The only way to eliminate the manual authoring burden is to stop writing test code entirely, and that is what Assrt does.
6. Frequently Asked Questions
Does Assrt replace Playwright or sit on top of it?
Assrt sits on top of Playwright. The browser engine is still Playwright's Chromium instance, and every click, type, and navigation is a Playwright MCP tool call under the hood. What Assrt replaces is the manual part: writing selectors, chaining assertions, maintaining brittle test code. You write plain English scenarios, and the AI agent translates them into Playwright actions at runtime.
What does 'open source' mean here specifically?
The MCP package (@assrt-ai/assrt) is MIT licensed. The agent loop, all 18 tool definitions, the scenario parser, and the system prompt are TypeScript source code you can read in src/core/agent.ts. You can fork the repo, add custom tools, change the system prompt, or swap the LLM model. There is no compiled binary or proprietary runtime.
How much does it cost?
Assrt itself is free. You pay for the LLM API calls (Claude or Gemini) that power the agent's reasoning. A typical test scenario with 10 to 20 steps costs a few cents in API usage. There is no per-seat fee, no monthly subscription, and no usage-based platform charge.
Can I run this entirely on my own infrastructure?
Yes. Install the CLI with npm install -g @assrt-ai/assrt, point it at your local dev server, and run tests. The browser launches locally, screenshots stay on your disk, and the only external call is to the LLM API. For teams behind a VPN or in regulated industries, your application's DOM and test data never leave your network.
What happens when the UI changes and tests break?
Because the agent reads the accessibility tree at runtime and matches elements by description rather than CSS selector or XPath, minor UI changes (renamed classes, restructured DOM, moved buttons) do not break tests. The agent finds elements the way a human would: by reading what is on screen. If a button's text changes from 'Submit' to 'Save,' you update one word in your test plan, not a chain of selectors.
How do I write a test scenario?
Write plain text using the #Case N: format. For example: '#Case 1: Login flow' followed by lines like 'Navigate to the login page,' 'Type test@example.com into the email field,' 'Click Sign In,' 'Assert that the dashboard loads.' The agent's parser splits on the #Case header and executes each case independently.
Can I add my own tools to the agent?
Yes. The TOOLS array in agent.ts is a standard TypeScript array of tool definitions with name, description, and input_schema fields. Add a new object to the array (for example, a check_database tool that queries your PostgreSQL instance) and handle it in the tool dispatch function. The agent reads tool descriptions at runtime and will use your custom tool when the test plan calls for it.
Keep Playwright. Ditch the Manual Work.
Assrt is MIT licensed, free, and self-hostable. Install the CLI, write a test plan in plain English, and let the AI agent handle the rest. Your tests, your infrastructure, your code.