# QA tools for coding agents: 10 ways to check what Claude Code, Cursor and Codex ship > Ten QA tools that check what Claude Code, Cursor and Codex ship, compared on who writes the tests, where they live and whether anything opens the running app. Source: https://qa.tech/blog/qa-tools-for-coding-agents ยท Published: 2026-10-22 --- Your coding agent can open a pull request every few minutes. Something has to decide whether the change works before it merges, and the tools sold for that job split on one question: does the agent that wrote the code also write the test that grades it? We build one of these tools, QA.tech, so read the ranking with that in mind. We've tried to describe every tool from its own docs, all checked on 21 October 2026. ## TL;DR
- **If you want a second opinion on every PR:** QA.tech, Spur or QA Wolf. A separate system tests the deployed preview and reports on the pull request. With QA.tech and QA Wolf, the vendor's agents write the tests; with Spur, your coding agent can. - **If you want your agent to write tests into your repo:** Momentic, TestMu's Kane CLI, or Playwright's own MCP and test agents. Good for the agent's feedback loop while it builds. You own and maintain the suite. - **If you want a cloud test agent your coding agent can call:** TestSprite or mabl. - **If you only need the agent to see the browser while it debugs:** Chrome DevTools MCP or BrowserStack's MCP server. Neither gives you a suite.
## Contents - Quick comparison - Why "who writes the test" is the first question - Category 1: Independent checks on the pull request - Category 2: Tools your coding agent drives to write tests into your repo - Category 3: Cloud test agents your coding agent calls - Category 4: Browser access for the agent's own debugging - How to choose - FAQ ## Quick comparison | Tool | How your coding agent reaches it | Who writes the tests | Where tests live | Tests the running app? | |---|---|---|---|---| | **QA.tech** | MCP server, CLI, GitHub/GitLab PR review | QA.tech's agents, from the PR, ticket and diff | QA.tech (export as JSON) | Yes, the PR preview | | Spur | MCP, GitHub Actions or GitLab CI check | Your coding agent drafts from the diff | Spur workspace | Yes, any URL | | QA Wolf | MCP server, CLI | QA Wolf's agents (or its team, managed) | QA Wolf, as Playwright | Yes, staging | | Momentic | Local MCP, skills, CLI in CI | Your coding agent | Your repo, YAML | Yes, local or CI browser | | Playwright MCP + Test Agents | MCP or Playwright CLI | Your coding agent | Your repo, Playwright code | Yes, local browser | | TestMu Kane CLI | Skill file or AGENTS.md | Your coding agent | Your repo, Markdown | Yes, local Chrome | | TestSprite | MCP server, CLI with skill | TestSprite's agent or yours | TestSprite cloud | Yes, cloud runs | | mabl | Cloud MCP, CLI skills | Your coding agent, in mabl's format | mabl | Yes, local or cloud | | Chrome DevTools MCP | MCP or CLI | Nobody, no suite | Nowhere | Yes, live Chrome | | BrowserStack MCP | Local or remote MCP | You, as before | Your repo | Yes, on its grid | ## Why "who writes the test" is the first question When the agent that wrote the code also writes the test, a green run proves less than it looks. [METR](https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/) had maintainers of scikit-learn, Sphinx and pytest review AI pull requests that had already passed the benchmark's tests, and roughly half wouldn't have been merged. [Vilhelm von Ehrenheim](https://www.linkedin.com/in/vilhelm-von-ehrenheim/), our co-founder and Chief AI Officer, likes agents writing tests as feedback while they build. But "if they're writing the tasks [tests] and the implementation at the same time themselves, there's still a huge risk for bias," so you also want a check "that is not controlled by the agent loop itself." Category 2 below is the feedback loop; category 1 is that outside check. ## Category 1: Independent checks on the pull request These tools sit outside the coding agent's loop. A pull request opens, a preview deploys, and something that didn't write the change tests it and reports back on the PR. ### 1. QA.tech QA.tech, an agentic QA platform, reviews pull requests by testing the deployed preview, the way a person would click through it. The agent reads the [PR description, any linked Jira or Linear ticket, the changed files and the commit messages](https://docs.qa.tech/best-practices/pr-testing), matches the change against the test cases you already have, and [writes new ones only where coverage is missing](https://docs.qa.tech/pr-testing/overview). How deep it goes depends on the blast radius of the change. Then it posts one review comment on the PR with a verdict: pass, fail, or unable to verify. ![Example of a QA.tech review posted on a pull request: a medium-risk change across three CRM surfaces, eight tests run, one failure with a screenshot of the deal page missing its health badge](https://qa.tech/compare-assets/qa-tech-pr-review-example-acme-signal-pr-46.webp) *What that review looks like, from [our demo CRM](https://github.com/QAdottech/acme-signal/pull/46): the new health badge worked on the pipeline board and the deals list, and was missing on the deal's own detail page.* Your coding agent comes in on the other side. QA.tech's [MCP server](https://docs.qa.tech/integrations/mcp) has documented setup for Claude Code, Cursor and Codex, and exposes the run results, screenshots, logs and traces, so the agent can read why a test failed and fix it. [Daniel Mauno Pettersson](https://www.linkedin.com/in/danielmaunopettersson/), our co-founder and CEO, describes two routes in: the PR, because every coding agent already knows what a PR is, and MCP, so the agent, in his words (Swedish, our translation), "can go to QA.tech and ask how my tests went, what's wrong, what should I fix, and then iterate on it." The agent can read the verdict and can add test cases over MCP, but the PR review picks and writes its own. It won't catch a side effect that never shows up in the UI or an API response. What it removes is the hand-run click-through on every preview. The check registers on GitHub as "QA.tech / PR Review", which you can [require in branch protection](https://docs.qa.tech/pr-testing/github), and on GitHub a post-merge agent can promote the test cases a review created into your regression suite. Web tests run in a Chromium-based browser and mobile on simulators and emulators, and test cases export as JSON, not Playwright code. **Pick it if** your agents ship more PRs than anyone can click through, and you want the check done by something other than the agent that wrote the change. **Skip it if** you need Safari or Firefox engines, or real-device mobile today. ### 2. Spur Spur is aimed at e-commerce teams and tests from the outside against a URL. Its MCP server has configs for Cursor, Claude Code, Claude Desktop, ChatGPT and VS Code with Copilot; Codex isn't named. The documented workflow is to point Claude Code at a pull request, let it read the diff and draft plain-English test steps, then run them through GitHub Actions with a status check (or GitLab merge request check) that can block the merge. So the coding agent drafts the tests from its own diff, and they run on Spur's hosted browsers and device labs. Sites behind bot protection need Spur's static IPs allowlisted. **Pick it if** you run a storefront and want plain-English tests with a merge gate. **Skip it if** you build SaaS or any product that isn't a storefront, you're on Bitbucket, or you want the tests written by something other than the agent that made the change. ### 3. QA Wolf QA Wolf's agents write deterministic Playwright tests and run them on every change, typically pointed at your staging environment. An [MCP server shipped on 29 September](https://www.qawolf.com/changelog/qawolf-mcp) for Codex, Claude Code and other MCP clients, so your agent can manage flows and runs, open issues, and ask QA Wolf's own agent to create or run tests. If you'd rather not own any of it, Coverage-as-a-Service puts their team on writing and maintaining the suite. **Pick it if** you want deterministic Playwright tests written for you, or want QA handed to someone else entirely. **Skip it if** you want each PR tested on what it changed, or you'd rather not hand control of your tests to an outside team. ## Category 2: Tools your coding agent drives to write tests into your repo Here the coding agent does the authoring, usually through an MCP server or a skill, and the tests land in your repository next to the code. That's useful while the agent builds. Vilhelm's view is that tests an agent writes for itself are "for kind of collecting evidence for itself, as it's building," which is different from deciding whether the change meets your bar. An engineering lead at a consumer products company described what happened to their suite once the team started vibe coding: "now, when we are vibe coding, everything just breaks. So it takes too much time to update the Playwright Test and everybody gets bored by playwright." Every tool in this category hands you a suite, which means it hands you that maintenance too. ### 4. Momentic Momentic gives Claude Code, Cursor, Codex, OpenCode, Copilot and Devin a local MCP server, plus skills for writing, speccing and maintaining tests. The agent writes plain-English YAML tests into your repo, engineers review them in the PR, and `npx momentic run` executes them in CI with an exit code that can gate the merge. Their docs describe the MCP as "a local server for your editor"; CI uses the CLI. [Authoring and running tests in Momentic's cloud is deprecated](https://momentic.ai/docs/get-started/cloud-deprecation), so the CI wiring, environment variables and schedules have all moved onto your team. Mobile needs a separate MCP server. And the tests come from the same agent that wrote the change, so a green run mostly tells you the agent agrees with itself. A co-founder at a SaaS company that had used Momentic described the other problem: "we've had issues with non-determinism, with Momentic, where if it's an agent each time, it sometimes chooses a different path to get to the thing." **Pick it if** you have engineers with time to own a YAML suite and its CI, and you're comfortable with the coding agent grading its own work. **Skip it if** you're trying to get out of maintaining a suite, or you want the PR verdict from something other than the agent that wrote the change. ### 5. Playwright MCP and Playwright Test Agents The first-party, open-source option. [Playwright MCP](https://github.com/microsoft/playwright-mcp) lets Claude Code, Codex, Cursor, Copilot and Windsurf drive a real browser through accessibility snapshots, and [`npx playwright init-agents`](https://playwright.dev/docs/test-agents) adds a planner, a generator that writes `.spec.ts` files from a Markdown plan, and a healer that repairs failing tests. Microsoft's own README now recommends the Playwright CLI over MCP for coding agents because it uses fewer tokens. Everything after generation is yours: the suite, the CI, the browsers, the flake triage. The README also warns that Playwright MCP isn't a security boundary. And the cost isn't zero just because the licence is. Daniel's observation from customer calls is that teams building this themselves often end up paying more than a product would, because nobody tuned which model runs which task (in Swedish, our translation): "You can throw Claude Opus at something and it'll just take 25 minutes and cost 40 dollars." We've compared the two approaches in more detail in [QA.tech vs Claude with Playwright](https://qa.tech/compare/qa-tech-vs-claude-playwright), and there's a setup guide in [getting started with Playwright MCP](https://qa.tech/blog/getting-started-with-playwright-mcp). **Pick it if** you have engineers who want Playwright code in the repo and time to keep it green. **Skip it if** the reason you're looking is that nobody wants to maintain Playwright tests. ### 6. TestMu AI Kane CLI TestMu, formerly LambdaTest, ships Kane CLI as a skill file for Claude Code, Codex CLI and Gemini CLI, and through `AGENTS.md` for Cursor and Copilot. There's no MCP server in that integration. The agent writes plain-English `_test.md` files that you can commit, and runs them in a real Chrome against localhost or staging, with an evidence pack per run. Their own docs set the limits. Each objective should stay under roughly fifteen steps, and editing step N re-authors every step after it, so fixing something early in a flow rewrites the rest of it. Every parallel run starts its own Chrome. And as with everything in this category, the agent that wrote the change also writes the test. **Pick it if** you already pay for TestMu's grid and want short smoke checks your agent can write in Markdown. **Skip it if** your important flows run past fifteen steps, you want an MCP integration, or you want the test written by something other than the agent that made the change. ## Category 3: Cloud test agents your coding agent calls These keep the tests on the vendor's side and give your coding agent a way to trigger and read them. ### 7. TestSprite TestSprite generates a product spec, a test plan and the tests, runs them in its cloud against the live product, and returns failure details to the coding agent. It connects through a CLI that installs a skill and an MCP server, and names Claude Code, Codex, Cursor, Windsurf, Copilot and several others. It also lists GitHub PR auto-testing. The limits are in its own docs: the MCP server is "not CI-compatible", the CLI can't target localhost without the MCP tunnel, and execution is cloud-only. We wrote a longer comparison in [TestSprite alternatives](https://qa.tech/compare/testsprite-alternatives). **Pick it if** you want tests generated from intent with almost no setup. **Skip it if** you need to test localhost from CI or want the tests stored outside the vendor's cloud. ### 8. mabl mabl moved to a cloud MCP server when it [retired the local one](https://help.mabl.com/hc/en-us/articles/47299375773844-mabl-MCP-overview) on 25 August, and adds CLI skills that install into Claude, Cursor, VS Code or Copilot. Through them the coding agent can query results, investigate failures, and author or edit mabl tests, which live in mabl's own format on its platform. Tests run locally or in mabl's cloud, and editing one from the agent needs its test ID. **Pick it if** you're already on mabl and want your coding agent to work inside it. **Skip it if** you're starting fresh and don't want a low-code platform's format to be where your tests live. ## Category 4: Browser access for the agent's own debugging Neither of these builds a test suite. They give the coding agent eyes on a browser while it works. ### 9. Chrome DevTools MCP Google's [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp) lets Claude Code, Codex, Cursor and Copilot inspect a live Chrome: network requests, console errors with source-mapped stack traces, performance traces, screenshots and Lighthouse audits. It's useful for an agent chasing a bug it introduced. It keeps no tests, so nothing runs again on the next PR. It supports Chrome only, it exposes the browser's content to the MCP client, and it collects usage statistics unless you opt out. **Pick it if** your agent keeps shipping front-end bugs it could have seen in the console. **Skip it if** you need anything that persists between pull requests. ### 10. BrowserStack MCP server BrowserStack's [MCP server](https://www.browserstack.com/docs/browserstack-mcp-server/overview) puts its browser and device grid in reach of your coding agent: live sessions, including locally hosted projects, runs of your existing Playwright or Selenium suites, accessibility scans, and AI agents for failure analysis and test-case generation. It runs the suite you have rather than writing one. A test automation lead at a large B2B SaaS company had his team trying agentic browsers and BrowserStack's MCP. "Sometimes it doesn't work. Sometimes it takes a long time to figure it out where the button is," he said, and getting it into the PR so that whole user flows were covered wasn't happening either. **Pick it if** you already pay for BrowserStack and want your agent to run existing suites across browsers. **Skip it if** you don't have a suite worth running. ## How to choose Start with where your agent's work gets merged. If nobody can keep up with the PRs, look at category 1, and ask each vendor who writes the tests and what happens when a run never reaches the change. A verifier with no "couldn't tell" state will go green on things it never checked. If your problem is the agent going in circles while it builds, a category 2 tool or plain Playwright MCP will tighten its loop. Budget for the suite you'll end up owning. If your team is mostly Copilot inside GitHub and the code review it gives feels good enough, that's a fair place to be. Review reads the diff, though, and doesn't run the product. Our guide to [verifying the work of coding agents](https://qa.tech/blog/how-to-verify-coding-agent-work) lays out which check catches what. And whatever you choose, keep the regression suite small: the flows that must never break, run on a schedule, plus testing on every pull request scoped to what changed. A suite that grows with every agent PR is the thing that slows you down next quarter. ## FAQ ### Which QA tools work with Claude Code, Cursor and Codex? All ten here connect to at least one of them, mostly over MCP. QA.tech, Momentic, TestSprite, Playwright MCP and Chrome DevTools MCP document all three. Spur doesn't name Codex. TestMu uses a skill file for Claude Code and Codex and `AGENTS.md` for Cursor. Check each vendor's docs for current setup steps, because these pages changed several times this autumn. ### Can a coding agent test its own work? It can, and it should, while it builds. The problem is using that as the verdict. The same agent that misread the ticket will write a test that agrees with its misreading, and both will pass. [METR found](https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/) that roughly half of test-passing AI pull requests wouldn't have been merged by the projects' maintainers. ### Can't I just give Claude Code Playwright MCP? You can, and it's where a lot of teams start. You get a browser the agent can drive and, with Playwright's test agents, generated specs in your repo. What you don't get is someone else checking the work, a PR verdict, or anyone but you maintaining the suite. In the [2025 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2025/ai), "AI solutions that are almost right, but not quite" was the most-cited frustration with AI tools, named by 66% of respondents, and an agent grading its own almost-right code won't notice. ### Do agent-written tests belong in my repo? If they're Playwright or YAML that your team will maintain, yes, version them with the code. If the tool tests from intent on each PR, there's less to keep: a short regression suite for critical flows, and the rest generated against the change. Category 2 tools assume the first model, category 1 tools mostly the second. ### How do I test a pull request's preview deployment? You need the preview URL and something that runs against it when the PR updates. The usual route is GitHub Deployments: [Vercel, Netlify, Render, Railway and Fly.io create a deployment record with the preview URL](https://docs.qa.tech/configuration/github-deployments) when they're connected to GitHub, and the testing tool picks it up from there. If you deploy previews from GitHub Actions yourself, you'll need to create that record. Without a preview environment, run the check against staging after merge and post the result on the merged PR. ### Are these tools a replacement for AI code review? No. A review bot reads the diff and catches what's visible in code. The category 1 tools open the app instead and report what happened there. ## Related reading - [How to verify the work of coding agents](https://qa.tech/blog/how-to-verify-coding-agent-work) - [Harness engineering: the sensor your agent harness is missing](https://qa.tech/blog/harness-engineering-behaviour-sensor) - [The 12 best agentic QA tools in 2026](https://qa.tech/blog/best-agentic-qa-tools-in-2026) - [What is dynamic testing?](https://qa.tech/blog/what-is-dynamic-testing)