How to test an app built with Cursor or Windsurf

Cursor and Windsurf are AI code editors. Cursor's site describes it as an AI coding agent for building software; Windsurf's site describes an AI-powered editor whose agent, Cascade, writes code, fixes issues and can fix test failures. This guide is for people who shipped an app with either one and want to know whether the deployed version works. You will get a test plan and a rules block that makes your assistant test after each deployment.

What the editors give you

Both tools help you write code and run your project's own checks. Windsurf's site mentions that you can preview and deploy from within the editor, and that you can connect tools through MCP. Cursor offers rules: persistent instructions included at the start of the model context. Those rules are the right place to ask for a post-deployment test.

What usually breaks in editor-built apps

Works on your machine, fails on the deployed address.
Environment values missing in production.
New accounts cannot sign in or confirm their email.
Layout breaks on a phone.
Error states are silent or show raw messages.
Accessibility gaps: contrast, labels, keyboard access.
Slow first load.

Pre-launch test plan

Run the build and your own tests locally.
Deploy to the real public address.
Open it in a private window on laptop and phone.
Click every menu and footer link.
Register a brand new account and confirm the email arrives.
Sign out, sign in, try a wrong password.
Run the main journey end to end.
Submit each form empty and with an unusual value.
Reach every control with the keyboard.
Check contrast and image text alternatives.
Visit a missing address and reload a deep page.
Look for debug output or exposed test data.
Read cookie and privacy notices.
Run an independent read-only test with Avalyz.
Fix S1 and S2 findings in the editor, redeploy, test again.

Add the Avalyz block to your rules

Cursor's documentation says Project Rules live in .cursor/rules, that AGENTS.md is a plain markdown file in the project root, and that a single .cursorrules file is still supported but deprecated, with a recommendation to migrate to Project Rules. Avalyz's integration is written for .cursorrules; if you use Project Rules or AGENTS.md, paste the same text there.

Title: "Avalyz acceptance test". Text: after every deployment, test the app with Avalyz (read-only by default) and read the report.
Run curl -sS --max-time 150 -X POST https://avalyz.com/api/v1/tests -H "Authorization: Bearer $AVALYZ_API_KEY" -H "Content-Type: application/json" -d '{"url":"YOUR_APP_URL","attendre":true}'.
Read the JSON: verdict (GO, GO SOUS CONDITIONS, NO-GO, INCONCLUSIF), pourquoi, constats (severity S1 to S4, title) and rapport_url (a path to append to https://avalyz.com).
If the verdict is not GO, fix the S1 and S2 findings, redeploy, run it again. If etat is en_cours, read https://avalyz.com/api/v1/tests/ID again with the same key.

Keep the key in the AVALYZ_API_KEY environment variable, never in the repository. Windsurf's site lists MCP support and rules for Cascade, so the same instructions and the MCP server file from the integrations page can be used there; check Windsurf's current documentation for where its rules and MCP configuration live. For CI, Avalyz also offers a GitHub Actions workflow on that page.

What an independent test adds

The assistant that wrote your code knows your intentions, so it tends to check what it meant to build. A separate tool that sees only the published address behaves like a visitor: it does not read your code and does not share the assistant's blind spots. Avalyz proves what it saw; it does not vouch for the rest, and a clean report is not proof that the app has no defects. It is a second pair of eyes, not a substitute for your own judgement.

Test your Cursor or Windsurf app with Avalyz

Avalyz tests a web application from the outside, in real browsers, and returns a verdict with evidence. Start free at /banc: paste your app's address, no sign-up, 3 tests a day. Or open https://avalyz.com/essai?url=YOUR_APP_URL with your own address in place of YOUR_APP_URL: it fills in the address and starts the test.

Read-only by default. By default, nothing is created or changed on your app. Only public addresses are accepted.
Optional test account. If your app has a login, give a test account: the sign-in form is then the sole form submitted, and the signed-in pages are explored read-only.
A GO / NO-GO verdict with evidence, findings ranked by severity, and a report you can paste back into Cursor or Windsurf so the fix goes to the tool that built the app.
Plans, in US dollars with no commitment, are on /tarifs; there is also a 14-day trial of the Pro plan with no card.

FAQ

What is Cursor?

Its site describes an AI coding agent for building software, with a desktop app, a CLI and agents that work in parallel.

What is Windsurf?

Its site describes an AI-powered code editor with the Cascade agent, rules, memories and MCP support.

Is `.cursorrules` still valid?

Cursor's documentation says it is still supported but deprecated, and recommends Project Rules.

Do I need a key to test?

No for the free test and the link. Yes for the command, MCP and CI.

Does the test read my code?

No. It tests the published app from outside, read-only by default.

Related guides: Test an app built with Claude Code, Test a vibe-coded app, Test a v0 app. Overview of every tool: AI app builders.