Testing with Cursor

Build an evidence-based test workflow in Cursor, review generated changes, and use ContextQA MCP for shared browser tests and portable test code.

Quick answer

Use Cursor to connect a code change to its expected behavior, implement tests in your existing framework, and run them from the repository. For browser workflows managed outside that repository, connect ContextQA MCP and review the created test before execution. Keep the code diff, test verdict and execution evidence together so a reviewer can tell what was actually checked.

This guide follows an illustrative permissions change: an organization viewer can read a project but cannot edit or delete it; an editor can update it. This example suits Cursor's editor workflow because the UI, API and authorization policy can be reviewed side by side.

Prerequisites

Open the repository in Cursor with its existing development dependencies available. Have a written permission matrix, an isolated test tenant, viewer/editor test accounts, and the current branch or preview deployment. Check that the accounts really have different roles; mislabeled fixtures can make a broken permission check appear correct.

Cursor Agent can inspect files, make edits and invoke terminal tools; use the official Agent overview for the current interface. The prompts below define a proposed testing approach, not a promise that every repository has the same commands or framework.

1. Give Cursor a precise slice of the application

In Agent, reference the actual permission policy, relevant route, UI component and existing tests. Ask for discovery before edits:

Inspect the project-role change in this branch and the related existing tests.
Read the repository instructions and identify the commands for unit, API
integration and browser tests. Map each changed file to affected behavior.
Do not edit files yet. Flag unrelated work and failures already present.

Run the existing focused tests. Save the result and the commit identifier. This baseline helps separate a new authorization regression from a fixture service that was already unavailable.

2. Define the permission matrix outside the implementation

Specify the intended outcome independently of the current code:

Actor	Read project	Edit project	Delete project
Viewer in the same tenant	Allowed	Denied	Denied
Editor in the same tenant	Allowed	Allowed	Use the documented policy
User in another tenant	Denied	Denied	Denied
Unauthenticated client	Denied	Denied	Denied

The editor's delete permission is intentionally not invented. Resolve it from your product specification before adding an assertion. Also specify the expected error contract: status, safe message and absence of a database change.

Use this approved matrix as the test oracle. Propose tests for each rule at
the lowest useful layer. A hidden Edit button is insufficient: denied writes
must also be tested at the server boundary. Identify ambiguous requirements.
Never infer a permission merely because the current handler allows it.

3. Implement focused unit and integration checks

Keep policy tests small, with explicit role/tenant inputs. Integration tests should exercise the actual authorization boundary and check stored state after a denied request.

Add unit tests for the approved policy decisions using this repository's
existing runner. Then add an integration test where a viewer directly submits
an update request: assert the documented denial and verify the project remains
unchanged. Add a cross-tenant request using two disposable fixtures.
Avoid mocking the authorization function under test. Isolate and clean up the
fixtures. Run the focused suites and show the actual command output.

Read the diff before accepting the change. Look for modified expectations, removed tests, broad snapshots and mocks that replace the very boundary the test claims to cover. Follow the unit and integration testing guides when choosing fixture boundaries.

4. Add the functional browser scenario

A browser test should check the experience as well as the underlying rule:

Using our existing browser framework, test the viewer's project screen in the
isolated tenant. Verify project details are readable and editing controls are
unavailable according to the product specification. In a separate fresh editor
session, edit a safe field and verify it persists after reload. Keep accounts
and browser state isolated. Capture failure evidence and do not add fixed
sleeps to mask synchronization problems.

Prefer a small journey with strong assertions over dozens of clicks. See functional testing, end-to-end testing and Playwright testing. A browser trace is useful evidence, but the absence of an exception does not prove that a permission rule held.

5. Add ContextQA to Cursor

Merge this entry into .cursor/mcp.json for the project, or use ~/.cursor/mcp.json for your personal configuration. Preserve other servers already present:

{
  "mcpServers": {
    "contextqa": {
      "url": "https://mcp.contextqa.com/mcp"
    }
  }
}

Cursor supports remote MCP URLs and OAuth; see the official MCP configuration guide. In the MCP management area, connect ContextQA and finish its browser sign-in. The ContextQA setup guide documents the Tools & MCP connection path; interface labels can differ by Cursor release.

For Cursor CLI users with the same server configured:

agent mcp list
agent mcp login contextqa
agent mcp list-tools contextqa

These commands are documented in Cursor's CLI MCP guide. Authentication does not grant the remote server arbitrary access to repository files. Supply approved text or a supported reachable resource explicitly.

6. Add a shared ContextQA regression case

Start by inspecting the live tools and existing workspace coverage:

Using read-only ContextQA tools, find existing project-role tests and inspect
their steps. List the available test environments. Show the current tool schemas
for creating, executing and retrieving results. Do not create or run tests.

Choose a missing browser scenario, then provide the reviewed acceptance criteria and reachable test URL. The remote runner needs network access to the application; a URL accessible only in your local Cursor terminal may not work.

Create one ContextQA case for the approved viewer UI scenario at [test URL],
using our configured viewer fixture. Include the expected readable fields and
the forbidden edit action's expected outcome. Keep the editor scenario in a
separate case/session. Return created IDs and complete steps for review.
Do not execute or change existing cases yet.

After review, execute only the chosen case IDs. Retrieve status, then the actual result and step evidence through the execution tools. Save the result ID alongside the branch/deployment identifier. Match evidence to that run, not a previous passing execution.

A correctly denied forbidden operation is a pass. A blocked login or unreachable tenant is inconclusive for the permission rule. “Created” means a case exists; “completed” means execution ended. Neither alone establishes success.

Review and export into your code workflow

Ask Cursor to summarize local and ContextQA results separately:

Produce a review table: requirement, test layer, test/case ID, command or result
ID, observed verdict and evidence. List skipped or blocked checks explicitly.
Do not combine local unit results with remote browser results into an invented
coverage percentage. Preserve the first failed attempt and any later rerun.

For repository-owned browser tests, inspect available export formats and use export and portability. Review generated selectors, fixtures and authorization assertions before running exported code in CI. A remote output path is not automatically a local file.

Troubleshooting and FAQ

Cursor changed too much. Narrow the request to named files and the approved matrix. Review and reject unrelated hunks before another iteration.

The viewer test passes using an editor account. Verify role/tenant setup before the action; separate sessions and inspect actual fixture identity.

ContextQA tools are missing. Check JSON syntax, the loaded server configuration, OAuth and workspace access. Use MCP troubleshooting, rather than bypassing permissions.

Should all tests move to ContextQA? Keep fast repository-native tests in their existing runner. Add managed application tests where shared execution and evidence solve a team need.

Start with one permission flow

Set up ContextQA MCP and create your first test. For help designing a shared regression workflow, book a ContextQA demo using one real change and your permission matrix.