Your coding agent can write a feature in ten minutes. The question is who checks it. This page compares the tools built for that job, and the two frameworks an agent reaches for when you give it none.
Judge each tool on three answers
Every tool here can drive a browser. They differ on what is left behind afterwards, so read the field in this order.
- Where the test lives. In your repository, where a reviewer reads the diff, or in a vendor's editor, where nobody does.
- Who repairs it when the button moves. You, the agent, the vendor's healing model, or the vendor's staff.
- What happens on the pull request. A dashboard someone has to remember, or a non-zero exit code that stops the merge.
Everything else, including MCP support, is downstream of those three. The claims below come from each vendor's own documentation and product pages, read in early 2026.
The field at a glance
| Tool | Where the test lives | How an agent drives it | Platforms | Best for |
|---|---|---|---|---|
| Momentic | Plain-English YAML in your repository | MCP server plus skills, and a CLI | Web, iOS, Android | Teams who want the test reviewed with the code it checks |
| Shiplight | Plain YAML in your repository, transpiled to Playwright at run time | MCP server plus skills | Web | Teams who want a Playwright artifact and an agent to write it |
| TestSprite | Generated tests the platform keeps and reruns | MCP server and an open-source CLI | Web and API | Getting a first suite from a URL in an afternoon |
| QA Wolf | Playwright and Appium code the vendor writes for you | CI integration, delivered as a service | Web, iOS, Android | Buying the QA function rather than a tool |
| Spur | Tests saved in Spur, written from a diff | MCP tools such as create_test, list_tests and run_tests | Web and mobile devices in Spur's cloud | Turning a pull request diff into coverage |
| Ranger | Playwright tests its web agent generates | CI/CD integration, with human triage in the loop | Web | Teams who want failures triaged before an engineer sees them |
| Revyl | Runs and evidence on Revyl's mobile platform | Cursor plugin, MCP, CLI and GitHub Actions | iOS and Android in the cloud | Mobile teams giving an agent a real device |
| Autonoma | Natural-language tests in an open-source platform you can host | Runs on every pull request | Web, iOS, Android | Teams who want the platform itself to be open source |
| Playwright or Appium | Code your team owns and maintains | The agent writes the code, and you run it | Web, or iOS and Android through Appium | Teams who want the framework and accept the upkeep |
Momentic
Momentic tests are plain-English YAML files in your repository. An agent writes them through the MCP server with the momentic-test, momentic-spec and momentic-maintain skills, and you review the change as a normal pull request diff. npx momentic run runs the same files locally and in CI, and exits non-zero on a failure, so the suite is a merge gate rather than a report.
Steps describe intent, not selectors, so a renamed class does not fail a test. A settled step replays from cache with no model call, and re-resolves against the page when the page changes. One authoring model covers web, iOS simulators and Android emulators.
Weigh against it: Momentic runs no physical device farm.
Shiplight
Shiplight is the closest thing here to Momentic. Its site describes plain YAML tests in your repository, an MCP server plus skills you install into Claude Code, Cursor or Codex, self-healing when a cached locator goes stale, and results on the pull request. Every YAML test transpiles to a standard Playwright test at run time, which is the honest answer to a lock-in question: you can eject and keep Playwright files.
Weigh against it: the browser is the whole product. If you also test iOS or Android, you carry a second tool.
TestSprite
TestSprite points at a running app, explores it, and writes the end-to-end tests you never got to. Its site describes a first pass of 50 to 100 tests from a URL, an open-source CLI, an MCP server for your editor, cloud execution, auto-healing, and runs on every pull request and on a nightly schedule. Failures come back as one bundle: the failing step, screenshots, DOM, a cause and a suggested fix.
Weigh against it: the platform generates and keeps the suite, so check how much of it you can read and edit before you depend on it.
QA Wolf
QA Wolf is a service more than a tool. Its agents map your app and write Playwright and Appium code, its infrastructure runs the suite fully in parallel, and its Coverage-as-a-Service tier puts QA engineers on your team with a coverage guarantee and unlimited maintenance. The generated code is open-source Playwright and Appium, and the site says it is yours to keep.
Weigh against it: an engineer in the editor does not author or run the suite. The contract does.
Spur
Spur puts the pull request at the start of the loop. Its MCP server gives Cursor, Claude Code or Copilot tools to read a diff, draft plain-English steps, save them with create_test, and run them with run_tests against real browsers and devices in Spur's cloud. Write calls ask for approval; read calls do not. It finds elements from the screen rather than from XPath or accessibility IDs.
Weigh against it: the tests live in Spur, so a reviewer reads them there and not in the diff.
Ranger
Ranger's web agent navigates your site and generates Playwright tests, runs them as your code changes, and triages the failures before your team sees them. Its comparison table claims the part most AI-only tools leave out: a QA expert reviews the result, so what reaches you is meant to be a real bug rather than a red run.
Weigh against it: browser only, and triage by a third party puts a person back in the loop you were trying to shorten.
Revyl
Revyl is mobile first. It gives an agent cloud iOS and Android devices to run and verify the change it just wrote, through a Cursor plugin, MCP, a CLI, GitHub Actions or the API. Atlas, its map of what your app does, is built from what the runs actually saw rather than from documentation.
Weigh against it: if the same team owns a web suite, this is not the tool that covers it.
Autonoma
Autonoma is an open-source agentic testing platform. Its repository describes natural-language tests for web, iOS and Android, runs on real devices and browsers, AI element detection and self-healing, and a check on every pull request. If your constraint is that the platform itself must be inspectable, start here.
Weigh against it: you run it. Hosting, devices and upgrades are your team's work.
Playwright or Appium with a coding agent
This is the default, and it is a real option. The agent writes the spec, you review the code, and nothing new enters your stack. It works well for the first fifty tests.
The cost arrives later. Selectors break on a class rename. Someone has to decide at 2am whether a red run is a regression, a flaky dependency or a stale locator, and an agent cannot answer that without the run history and the evidence to read. Mobile adds emulator and simulator provisioning. If you build the orchestration around the agent to cover that, you now maintain a test platform as well as an application.
How to run the evaluation
Vendor pages agree with each other too much to decide anything. Two weeks of your own product settles it.
- Give a coding agent the tool and one real feature. Count the turns before a test passes, and read what it wrote.
- Rename a button and rerun. A tool that heals says so; a tool that hides the change is worse than a failure.
- Break the product on purpose. The failure must arrive with enough evidence to find the cause without a rerun.
- Open a pull request. Check that a failure blocks the merge, and not only a dashboard.
- Ask where the test is, six months from now, if you stop paying.
Where to start
If you want the test in the same diff as the code it checks, start with Momentic . Connect the MCP server to your agent, write one test, and run it in CI with npx momentic run. The CLI page covers the command, and we can help you scope a pilot if you are comparing two of these side by side.