Guide
Generate Integration Tests With Cursor's Browser
Ask Cursor's agent to drive a flow in the integrated browser, then ask it to write an integration test from what it did. The agent clicks, types, scrolls and takes screenshots on a real page. By default, each browser action needs your approval. Read the assertions, and watch the test fail once before you keep it.
On this page
- What is Cursor's integrated browser?
- How do I get the agent to drive a browser flow?
- How does it turn that flow into an integration test?
- Why shouldn't I trust a test I didn't see fail?
- How do I stop Cursor writing tests that fail silently?
- How does Debug mode pair with browser testing?
- Can I report coverage and limits the same way?
What is Cursor's integrated browser?
It is a browser built into Cursor that the agent controls. The agent does real browser actions for you: it navigates to a page, clicks a button, applies a filter, scrolls and takes screenshots.
Cursor's browser docs describe it as a secure web view controlled by an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server that runs as an extension. In Cursor's QA workshop, the presenter said the integration captures each action's metadata as the agent works. The result is a recorded history of the elements the agent clicked and the pages it visited.
While the agent works, it shows its actions and screenshots in the chat. In the workshop demo, a banner reading "agent is using this browser" sat on the right and a step log streamed on the left. If you need a paper trail, ask the agent to write each page element it touches to a text file as it goes.
You don't install or configure Playwright or any other tool. The agent issues the browser actions, and the record of what it did is what a generated test is built from later. As the presenter put it: "our integrated browserCursor's built-in browser, driven by Playwright under the hood, so the agent can navigate, click, screenshot and capture each action's metadata while you watch. Press Enter for the full definition. actually has Playwright under the hood."
This is covered hands-on in MCP, Plugins and Integrations — 6 short Units, free to read.
Rather do it than read about it? Run 11 interactive Cursor walkthroughs in a simulated editor. Free, no account needed.
How do I get the agent to drive a browser flow?
Describe the flow in one prompt, step by step, and ask for screenshots as evidence. The agent picks up the browser tool, performs each step, waits for pages to load and takes a screenshot at each stage. In the workshop the target was a cat-adoption app, and the prompt was concrete:
Using the browser, navigate to the homepage. Click Browse Cats. Filter by senior cats. Scroll until 30 cats are populated. Take screenshots to show your work.
Expect the run to pause for you. By default, Cursor asks you to approve each browser action before the agent runs it. In Cursor's settings you can allow-list trusted actions or turn on auto-run, but Cursor's docs warn against auto-run with untrusted code or unfamiliar websites.
The clip below shows the same pattern on a keyboard accessibility check.
Tab to Apply, then confirm the focus ring and the name
0:41 · narratedRead this demo as text
- Ask the agent to actually tab to the Apply button on the live cart — not just glance at the screenshot. Focus order and focus visibility only show up when you drive the keyboard yourself.
- Switch to the Browser tab and watch the tab order: focus stops on the coupon field first, then lands on Apply with a visible blue ring. That's the order a real keyboard user would hit.
- The agent reads the accessible name straight off the focused control: Apply. Ring visible, name confirmed — that's a keyboard-safe control, not a guess from the layout.
Practice next: Practice this yourself in the hands-on module.
Simulated Cursor 3.12 (macOS, light) — beta educational reconstruction, not the real product.
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
The agent performs each action in the browser, the actions are captured, and one follow-up prompt turns that history into a test.
Live pages misbehave. In the demo, a bot check ("I am not a robot") interrupted opening a report. Pages can load slowly, and a scroll meant to stop at 30 items can overshoot to 60. Watch the step log instead of assuming the run went perfectly.
How does it turn that flow into an integration test?
Send one follow-up after the flow finishes: "based on this action, create an integration test in our suite." The agent reads back the history of clicked and navigated elements, pulls the metadata it captured and writes a test file. In the workshop, the new test landed next to the existing integration tests and followed their shape.
Cursor's agent can hand browser work to a built-in Browser subagent, which filters raw page snapshots and screenshots down to the relevant results. When that happens, the main conversation holds a summary rather than every step. A text-file log of the elements the agent touched gives the test step a fuller record to work from.
- 1Run the flow first, so the agent has a full action history to draw from.
- 2Ask for the test: "based on this action, create an integration test in our suite."
- 3Read the generated assertions. A test that asserts nothing is worse than no test.
- 4Wrap the whole loop in a reusable browser-automation skill so you can run it again.
A Cursor skill is a folder with a SKILL.md file that describes the workflow, plus optional deterministic scripts. Build a browser-automation skill that takes your prompt, drives the flow and writes the integration test. To run it, type / in Agent chat and pick the skill, or describe the task and let the agent load the skill when it judges it relevant.
Why shouldn't I trust a test I didn't see fail?
A generated test that passes on its first run may assert nothing at all. It might wrap its checks in a try/catch, or log a failure instead of calling the framework's fail method. This was the sharpest question of the workshop Q&A, and the presenter agreed with it: never trust an automated test you didn't see fail.
Never trust an automated test that you didn't see fail. You write tests based on existing code. You have no proof the test assets actually show something.
The fix is engineering discipline, not a Cursor setting. Before you generate anything, decide the golden state: the happy-path input and the output it should produce. Cursor can speed up your testing process, but it can't decide what "correct" means for you.
Give the agent the known-good input and expected output as the test's anchor, or have it follow a detailed plan you reviewed. Then open the file and check that each assertion would catch a regression. If you can, make the test fail on purpose once before you keep it.
How do I stop Cursor writing tests that fail silently?
Silent-fail tests take two shapes. In one, a log call stands in for the framework's fail method. In the other, an if or try/catch block around the validation swallows the assertion. Rules help, but the agent doesn't always follow them, especially deep into a long session. The workshop offered four remedies that work around that.
- Remedy
- Keep the rule lean and specific
- Why it works
- A short rule aimed at exactly this problem is more likely to be followed than a sprawling one.
- Remedy
- Keep the context window near-empty
- Why it works
- As a long conversation fills the window, rule context can get pushed out. A fresh, focused session keeps the rule in view.
- Remedy
- Add a validator skill or subagent
- Why it works
- A dedicated worker runs the test, reads the output and reruns it to confirm a real failure surfaces.
- Remedy
- Open a fresh agent for test runs
- Why it works
- On a complex suite, an agent that only runs tests isn't overloaded by unrelated subtasks.
| Remedy | Why it works |
|---|---|
| Keep the rule lean and specific | A short rule aimed at exactly this problem is more likely to be followed than a sprawling one. |
| Keep the context window near-empty | As a long conversation fills the window, rule context can get pushed out. A fresh, focused session keeps the rule in view. |
| Add a validator skill or subagent | A dedicated worker runs the test, reads the output and reruns it to confirm a real failure surfaces. |
| Open a fresh agent for test runs | On a complex suite, an agent that only runs tests isn't overloaded by unrelated subtasks. |
A lean rule, an empty context and a validator work better than one long rule file.
The presenter's explanation: after a long chat, rule context can get pushed out as the window fills. For a high-stakes test task, start a new agent and give it only that job.
How does Debug mode pair with browser testing?
When a browser flow turns up a bug, switch from Agent to Debug modeA mode that diagnoses a failure: it reproduces the issue, adds instrumentation and watches the logs, rather than reviewing a pull request. Press Enter for the full definition. in the mode picker for root-cause analysis. Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. has a bias for action: it finds the suspected spot and changes code. That solves most bugs, but it can over-edit on subtle, cross-service or deeply nested ones. Cursor's help says switching modes starts a fresh context window, so describe the bug and how to reproduce it in your first Debug mode message.
Debug modeA mode that diagnoses a failure: it reproduces the issue, adds instrumentation and watches the logs, rather than reviewing a pull request. Press Enter for the full definition. collects evidence before it changes code. The agent explores the relevant files and forms multiple hypotheses about the cause. It adds log statements that send data to a local debug server running in a Cursor extension, then gives you steps to reproduce the bug. It reads the logs, confirms or rejects each hypothesis and makes a targeted fix, often just a few lines. Once you confirm the fix, it removes all the instrumentation.
The workshop presenter described that debug server as a lightweight web server that only accepts requests. By that account, the language and layer don't matter as long as the code can POST JSON to it. That covers backend code, frontend code and even compiled executables.
During a Debug modeA mode that diagnoses a failure: it reproduces the issue, adds instrumentation and watches the logs, rather than reviewing a pull request. Press Enter for the full definition. run, the main agent may launch a subagent: a parallel worker with its own context window that takes one bucket of the task and returns the result. The same move parallelizes QA in general. One subagent can run a coverage report while another documents issues. If a job splits into independent parts, a subagent is a good fit.
Interactive widget. Tab through its controls; the result updates in the panel below as you change them.
A Debug mode run is one-off analyst work that ends in a fix. A browser-automation or coverage skill is builder work that your team runs again and again.
Can I report coverage and limits the same way?
Yes. Package coverage as a skill, in the same shape as the browser-automation one. The workshop's test-coverage skill ran coverage.sh, a pytest-coverage command, and formatted the result, including an HTML report. Trigger it with a slash command and a parameter, or ask "can you check my backend test coverage?" and let the agent find the skill from your prompt.
From there you can send the output to other tools. In the demo, the agent pushed the coverage report into Confluence through the Atlassian MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition., so the team could turn it into tickets. The presenter warned that the Atlassian MCP can be flaky in practice, so check that the page landed.
Some checks should stay human: deciding the golden state, signing off on what a test proves, and judging whether a passing suite protects the behavior you care about.
The browser opens inside the Cursor IDE, in a pane or a separate window. The Cursor CLICursor's command line: the full agent, all modes and models, in the terminal and pipeable into scripts and CI. Press Enter for the full definition. is terminal-native and can run headless. In JetBrains IDEs the agent runs through ACPAgent Client Protocol. An open standard that lets any IDE host any coding agent; Cursor uses it to run inside JetBrains/IntelliJ and Android Studio. Press Enter for the full definition., and Cursor's ACP docs list Agent, Plan and Ask as the modes for those sessions. Debug modeA mode that diagnoses a failure: it reproduces the issue, adds instrumentation and watches the logs, rather than reviewing a pull request. Press Enter for the full definition. is not one of them. Check Cursor's docs for each surface before you assume the browser works outside the IDE.
Frequently asked questions
Does Cursor's integrated browser run Playwright?
The presenter of Cursor's QA workshop said it does: "our integrated browser actually has Playwright under the hood." Cursor's browser docs don't mention Playwright. They describe a secure web view controlled by an MCP server running as an extension. Either way, the agent performs real browser actions and you set nothing up.
How do I turn a browser flow into an integration test?
Drive the flow with one prompt first. Then follow up with "based on this action, create an integration test in our suite." The agent reads the history of what it clicked and visited and writes the test next to your existing ones. Read the assertions before you keep it.
Why shouldn't I trust a generated test that passes?
A test that has only ever passed may assert nothing, or swallow failures in a try/catch or a log call. Anchor the test on a known golden state, read the assertions yourself, and make it fail once on purpose before you rely on it.
How do I stop Cursor generating silently-failing tests?
Keep the rule lean and specific, and keep the context window near-empty, since long sessions can push rules out. Add a validator skill or subagent that runs the test and confirms a real failure surfaces. For a complex suite, open a fresh agent that only runs tests.
When should I switch to Debug mode instead of Agent mode?
Switch for subtle, cross-service or deeply nested bugs, where Agent mode's bias for action can over-edit. Debug mode forms hypotheses, logs runtime data, has you reproduce the bug, makes a targeted fix and then removes the logging. Switch modes from the mode picker.
Can I reuse the browser-testing workflow?
Yes. Wrap it in a browser-automation skill: a SKILL.md that describes the workflow, plus optional scripts. The skill takes a prompt, drives the flow and writes a test. Run it from the / menu in Agent chat, or describe the task and let the agent pick the skill up.
Sources & last verified
- Cursor: Browser tool docs
- Cursor: agent modes and skills docs
- Cursor: Debug Mode docs
- Cursor: Subagents docs
- Cursor: ACP docs
- Cursor help: Agent modes
Cursor ships frequently. Last updated October 28, 2026.