How to Generate Cypress Tests Without Writing Code

You can generate Cypress tests without manually writing every selector and command in two ways: record a real user journey with Cypress Studio, or describe the journey in natural language with cy.prompt. Studio turns supported browser actions into Cypress commands. cy.prompt generates and runs commands from a list of steps. In both workflows, inspect the resulting test: generated code can save typing, but you still need to confirm it checks the behavior your application is supposed to provide.

Choose Studio when you can demonstrate the flow in the browser and want to build a conventional test spec. Choose cy.prompt when describing the steps is easier than recording them and you can use Cypress Cloud. For a specific uncovered control identified in a UI Coverage report, Cypress Cloud also offers a targeted draft-test workflow.

1. Choose a code-light workflow

Workflow	Best for	Requirements and tradeoffs
Cypress Studio	Recording a journey you can perform in the app	Studio records supported interactions and adds commands to a spec. Recording works without AI or Cypress Cloud. Studio needs internet access and sourcemaps to load test code accurately.
Studio AI	Getting suggested assertions based on observed UI changes	Requires a Cypress Cloud account and a linked project. Suggestions come from UI changes, not access to your source code, business logic, or backend rules.
`cy.prompt`	Describing a journey in words instead of demonstrating it	Requires Cypress Cloud connectivity or the documented recorded-run setup. You can export generated commands as static code or keep the prompt active for regeneration when relevant selectors or DOM details change.
UI Coverage Test Generation	Drafting a test for an uncovered interactive element found in a coverage report	A focused Cloud coverage workflow, rather than a general-purpose recorder for a first test.

Cypress documents these AI capabilities as available on its free Starter plan, with paid plans providing higher usage limits. Plan details and limits can change; check the current Cypress documentation before choosing a plan.

2. Set up a Cypress project

The generated-test workflows operate inside a Cypress project. If your project already runs Cypress, use its existing configuration and spec conventions. For a new JavaScript project, the following is a small runnable starting point using npm:

mkdir cypress-code-light
cd cypress-code-light
npm init -y
npm install --save-dev cypress

Add a script to package.json:

{
  "scripts": {
    "cy:open": "cypress open",
    "cy:run": "cypress run"
  }
}

Open Cypress and use its project setup flow to create the end-to-end testing structure:

npm run cy:open

For the standard interactive workflow, open Cypress App, choose the end-to-end testing option if prompted, and launch a browser. Put or keep your specs in the configured end-to-end spec folder (commonly cypress/e2e). Use the base URL and support-file conventions already established by your team. A small hand-authored spec is not required to record a test, but knowing where the generated commands belong makes the output easier to review and commit.

3. Record a test with Cypress Studio

Start the Cypress App and open your project in an interactive browser.
Open or create an end-to-end spec and visit the application page you want to test.
Use Studio’s recording controls to demonstrate the user journey.
Perform the supported actions: click, type, check, uncheck, and select.
Review the commands Studio adds to the spec in real time. Edit the code inline if needed.
Add assertions that express the expected result, then run the spec again from a clean starting state.
Save and commit the resulting spec so it runs with the rest of your suite.

Studio chooses selectors using a priority strategy. Cypress lists data-cy, data-test, data-testid, data-qa, name, id, class, tag, other attributes, and finally nth-child. You can customize priorities with Cypress.ElementSelector. Prefer stable test attributes when your application provides them; a recorded selector can still break when markup or repeated elements change.

Studio recording does not require AI. If you want Studio AI assertion recommendations, link the project to Cypress Cloud. Cypress says the suggestions may be tried without logging in up to six accepted recommendations in a browser session; verify the current limit in the Studio guide because product limits can change.

4. Generate a test from natural-language steps with cy.prompt

cy.prompt takes a list of natural-language steps. Cypress interprets each step, evaluates the DOM to find targets, generates Cypress commands, and executes them in sequence. This example is a runnable shape for a prompt test; adapt the URL and wording to the actual application and verify the generated commands in the Command Log.

describe('product search and cart', () => {
  it('finds a product and adds it to the cart', () => {
    cy.prompt([
      'Visit https://example.com/shop',
      'Search for headphones',
      'Open the headphones product',
      'Add the product to the cart',
      'Confirm the cart contains the headphones'
    ])
  })
})

Use concrete, observable steps. Name the item or control as it appears in the UI, and state the expected result. Avoid combining several actions into a vague instruction such as “complete checkout.” For authentication or sensitive fields, use your project’s approved test-data and secret-handling approach; do not put real credentials into a prompt or committed spec.

To run this workflow, connect the project to Cypress Cloud or use the documented --record setup with a valid key. Inspect the generated code through the Command Log’s Code control. Cypress documents two ways to use the result:

Generate once and commit: copy or export the commands into the spec, review them, and commit the static Cypress code. Cypress says the exported test then runs without calling the AI service.
Keep the prompt active: leave cy.prompt in the spec so Cypress can regenerate selectors when cached code is invalidated by relevant prompt or DOM changes. This can help with selector maintenance, but it does not establish that a changed flow still satisfies your business rules.

Cypress documents generated code as cached and shared across machines and environments, including CI, with another AI call when the prompt or relevant DOM change invalidates that code. Treat this as documented product behavior, not a guarantee of a particular speed or test accuracy.

5. Review generated tests before relying on them

Cypress states that generated code is visible and can be inspected, modified, copied, or saved into a test. Use that visibility as part of the workflow:

Check the target: confirm the selector points to the intended control, especially when a label, class, or repeated element could match more than one node.
Check the assertion: make sure it tests a meaningful outcome such as a confirmation, updated URL, or changed application state. A click succeeding is not proof that the intended business operation succeeded.
Check the starting state: identify required data, authentication, feature flags, and cleanup so reruns are consistent.
Check sensitive data: remove secrets and personal data from prompts, generated code, screenshots, and logs according to your project policy.
Check conventions: align base URL handling, test attributes, fixtures, and helper usage with the rest of the repository.
Run it more than once: a test that passes only with leftover browser state or a one-off network response is not a reliable regression check.

AI suggestions observe UI changes such as visibility, text, form values, attributes, and URL changes. Cypress says Studio AI does not have access to application source code, business logic, or backend rules. A person who understands the requirement must decide whether a suggestion proves the right thing.

6. Screenshot a page when visual evidence helps review

A screenshot can help a reviewer understand the UI state around a generated test or document a visual failure. It does not replace assertions: image evidence alone does not verify application logic. For a manual capture in Cypress, cy.screenshot() saves a screenshot during a run, for example:

describe('search page evidence', () => {
  it('captures the search result state', () => {
    cy.visit('/shop')
    cy.get('[data-cy=search]').type('headphones')
    cy.get('[data-cy=search-submit]').click()
    cy.get('[data-cy=search-results]').should('be.visible')
    cy.screenshot('search-results')
  })
})

Use the selectors your application actually exposes; the data-cy names above are examples. Cypress screenshots are useful for local or test-run evidence. If your task is to obtain a clean webpage image or PDF through an API, that is a separate capture workflow.

7. Troubleshooting

Symptom	Likely cause	Fix
Studio does not load the test code accurately	Studio requires internet access and sourcemaps.	Check connectivity and ensure the relevant application/build exposes sourcemaps as required by the Studio guide.
Studio AI assertion suggestions are unavailable	The project is not connected to Cypress Cloud, or the available recommendation allowance has been reached.	Link the project and confirm the current plan and trial limits. Continue recording without AI if you do not need suggestions.
`cy.prompt` cannot run or connect	The run is not authenticated with Cypress Cloud, or the documented recorded-run key is missing or invalid.	Sign in/connect the project or configure `--record` with a valid key as documented by Cypress. Check the current Cloud requirements.
A generated command selects the wrong element	Text, class, or positional selectors are ambiguous, or the DOM changed.	Inspect the generated selector, use a stable test attribute such as `data-cy` where appropriate, and edit/export the command. Consider selector-priority configuration for Studio.
The test passes but does not catch a real defect	The generated assertion checks a superficial UI change or misses the actual business rule.	Rewrite or add assertions based on the requirement and observable result; generated recommendations cannot infer backend rules.
The active prompt regenerates commands unexpectedly	A prompt or relevant DOM change invalidated cached generated code.	Inspect the new code and rerun the scenario. If stable, reviewed commands are preferred, export them and commit the static code.
The recorded test is flaky	It depends on transient data, animation, timing, third-party content, or state left by another test.	Make setup and data deterministic, wait on meaningful application conditions, isolate state, and rerun from a clean environment. Do not paper over a missing assertion with an arbitrary long delay.
A Cypress screenshot is missing	The screenshot command was not reached, the run failed earlier, or the output location differs from expectations.	Confirm the test reaches `cy.screenshot()` and consult the project’s Cypress screenshot/output configuration.

8. Performance, reliability, and cost

Studio recording itself is an interactive authoring workflow: its main dependency is being able to load the application and accurately map recorded interactions into test code. cy.prompt adds a Cloud-connected AI generation step. Cypress documents caching and shared generated code, and says an AI call is made again when relevant prompt or DOM changes invalidate the cache. No independent speed or accuracy benchmark is established by the documentation in this guide, so choose based on workflow fit and review burden rather than assumed time savings.

For reproducible CI runs, exported static Cypress commands avoid an AI service call during the test according to Cypress’s documentation. Keeping the prompt active offers selector regeneration behavior but introduces Cloud connectivity and regeneration as considerations. Both approaches still depend on a reachable application, stable test data, and assertions that reflect the requirement.

Cypress documents cy.prompt and Studio AI as available on its free Starter plan, with paid tiers raising execution allowances and hourly limits. Confirm current limits, plan terms, and Cloud requirements on Cypress’s official site before budgeting. Recording with Studio without AI does not require Cypress Cloud.

9. Or skip the browser setup

If what you need is a webpage screenshot for test review, documentation, or an agent workflow, ScreenshotNeo is a website screenshot API and MCP server. It is not a Cypress test generator; it handles the screenshot capture step.

One GET request returns a PNG, JPEG, WebP, or PDF. For example, this cURL request saves a WebP screenshot:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for the request options and configuration. Python and Node.js examples:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot; each cleanup step can be disabled. Bot checks, blank pages, timeouts, and failed loads are never billed, and responses identify the page verdict and billing state. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

10. Frequently asked questions

Can Cypress create a complete test suite from one instruction?

The documented workflows generate commands for demonstrated or described flows, and UI Coverage can draft a test around an identified coverage gap. They do not remove the need to choose scenarios, data, and expected behavior for a suite.

Can I use Cypress Studio without AI?

Yes. Studio can record supported interactions and add commands without Studio AI recommendations or a Cypress Cloud connection.

Does an active cy.prompt test guarantee self-healing?

Cypress documents regeneration of cached commands when relevant prompt or DOM changes invalidate them. You should inspect regenerated code and verify the application behavior; regeneration does not validate business intent.

Should I commit generated test code?

For predictable, version-controlled behavior, inspect and commit exported Cypress commands. Keep an active prompt when its documented regeneration behavior is useful and your team accepts its Cloud dependency.

Can a screenshot prove that a Cypress test passed?

A screenshot records visual output. Use Cypress assertions and test results to verify behavior; treat screenshots as supporting evidence.