> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/testing-with-ai-coding-agents/cursor-testing.md). # 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](https://cursor.com/docs/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](/testing-with-ai-coding-agents/unit-testing.md) and [integration testing](/testing-with-ai-coding-agents/integration-testing.md) 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](/testing-with-ai-coding-agents/functional-testing.md), [end-to-end testing](/testing-with-ai-coding-agents/end-to-end-testing.md) and [Playwright testing](/testing-with-ai-coding-agents/playwright-testing.md). 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: ```json { "mcpServers": { "contextqa": { "url": "https://mcp.contextqa.com/mcp" } } } ``` Cursor supports remote MCP URLs and OAuth; see the [official MCP configuration guide](https://cursor.com/docs/mcp). In the MCP management area, connect ContextQA and finish its browser sign-in. The [ContextQA setup guide](https://mcp.contextqa.com/docs) documents the Tools & MCP connection path; interface labels can differ by Cursor release. For Cursor CLI users with the same server configured: ```bash agent mcp list agent mcp login contextqa agent mcp list-tools contextqa ``` These commands are documented in [Cursor's CLI MCP guide](https://cursor.com/docs/cli/mcp). 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](/mcp-server/tool-reference/execution-and-results.md). 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](/testing-with-ai-coding-agents/export-and-portability.md). 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](/mcp-server/troubleshooting.md), 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](/mcp-server/installation-and-setup.md). For help designing a shared regression workflow, [book a ContextQA demo](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=cursor-testing) using one real change and your permission matrix. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://learning.contextqa.com/testing-with-ai-coding-agents/cursor-testing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.