AI Prompts for Cypress Test Automation: A Practical Guide

Updated 8 November 2026 · Standard formula, shown below

AI prompts can help you draft Cypress tests, expand coverage, and diagnose failures faster, but generated code still needs review. Start with a clear description of the behavior you want to verify, then ask for a small, runnable test that matches your app and Cypress setup.

What You’ll Need

A web application you can run in a test or staging environment, plus a known URL and test data.
A Cypress project with its dependencies installed and an existing way to open or run tests. If Cypress is not set up, follow its current installation guidance for your project first.
An AI assistant that can generate or explain code. Do not paste credentials, personal data, private customer information, or confidential source code into a service unless your organization permits it.
Basic familiarity with JavaScript or TypeScript, Cypress commands, and your app’s selectors and expected behavior.

Step-by-Step

Choose one behavior to test. Avoid asking for an entire test suite in one prompt. Pick a user-visible outcome, such as submitting a valid sign-in form and seeing the dashboard. State what must be true before the action, what the user does, and what should happen afterward. Include relevant validation or error cases if they are part of the goal.
Gather the details the assistant cannot infer. Note the page or route, stable selectors, test data, and any setup requirements. Prefer accessible selectors such as a role and accessible name or a label, where your app supports them. If your project uses a consistent attribute such as data-cy, provide the exact attribute and value. Do not expect an assistant to know your DOM, custom commands, fixtures, or authentication setup without being shown them.
Write a constrained prompt. Tell the assistant what to create, the language, the Cypress version or conventions if relevant, and what it must avoid. Ask for one spec file and explain how the test should be independent and deterministic. For example: Write a Cypress end-to-end test in JavaScript for the sign-in flow at /login. Use the selectors I provide: [data-cy=email], [data-cy=password], [data-cy=submit]. Given a valid test account available through our existing test setup, submit the form and assert that the dashboard heading is visible. Do not invent selectors, credentials, APIs, or project configuration. Return the test, then list assumptions and anything I must verify.
Inspect the draft before adding it. Check that Cypress commands and assertions are valid for your installed setup, that selectors match the app, and that the test checks an observable result rather than implementation details. Remove invented credentials or assumptions. Confirm any suggested helper, fixture, intercept, plugin, or configuration change against your repository before using it.
Save the test in the right place. Follow the folder structure and naming conventions already used in your project. Keep the initial test focused. Do not let generated code change Cypress configuration, package files, or application code unless that change is necessary and you understand its effect. Use a dedicated test account or approved test data, not a real user’s account.
Run the test locally. Open Cypress for interactive inspection or run it with your project’s existing command. Make sure the app is available at the configured base URL and that required test data and services are ready. Watch the test execute; a passing result alone does not prove the intended user journey was checked.
Verify the assertion and the failure behavior. Confirm the test fails when the expected behavior is absent, and passes when it is present. If it fails, read the Cypress error and command log, inspect the page and selector, and check whether the failure is due to setup, timing, data, or a real application defect. Fix the underlying cause rather than weakening the assertion to force a pass.
Use follow-up prompts to refine, not obscure. Share a short, sanitized failure message or relevant test snippet and ask for likely causes or a minimal correction. Ask the assistant to explain each change. If the diagnosis depends on information it does not have, provide that information or investigate directly instead of accepting a guessed fix.
Review coverage and keep the test maintainable. Ask for a separate test for an important validation or error state rather than piling unrelated cases into one test. Remove redundant waits and duplicated setup. Once the test is stable, run the project’s relevant suite and include the change in normal code review.

Common Mistakes

Vague prompts: “Test the login page” leaves expected behavior and test data unclear. Specify the action, outcome, and relevant edge case.
Invented selectors or APIs: Generated code may look plausible but target elements or endpoints that do not exist. Give real selectors and verify every interaction.
Using brittle selectors: Styling classes and deep DOM paths can change without a behavior change. Prefer accessible locators or stable test attributes that your team maintains.
Masking timing problems: Fixed delays such as cy.wait(5000) make tests slower and can still fail. Wait for a meaningful UI state or a specific request when appropriate.
Testing only that a click worked: An interaction is not proof of success. Assert the resulting heading, URL, message, or other user-visible state.
Trusting generated setup blindly: A suggested login helper or network intercept may bypass the behavior you intended to test. Decide whether the test is checking the UI flow or a faster, separately validated setup path.

Tips

Provide a small, relevant example from your existing Cypress tests so generated code can follow established patterns.
Ask for assumptions to be listed separately from code. This makes missing selectors, setup steps, and test data easy to spot.
Request one change at a time: first draft the test, then explain a failure, then refactor if needed. Smaller outputs are easier to verify.
Use realistic but non-sensitive test data. Keep secrets in approved environment or CI configuration, not in prompts or committed test files.
Ask for independent tests that can run repeatedly and in different orders. Avoid relying on state left by another test.
Treat AI output as a code suggestion. Your project’s tests, Cypress documentation, and observed application behavior are the sources to check.

Troubleshooting

The test cannot find an element: Check the selector in the running page, confirm the correct route loaded, and verify that the element is visible and accessible at that point. Share the actual markup or a sanitized DOM excerpt in a follow-up prompt if useful; ask for a selector based only on what you provide.

The test times out: Determine which command timed out from the Cypress command log. Check whether the app or API is slow, the expected state never occurs, or the test data is missing. Wait for the relevant state or request instead of adding an arbitrary long delay.

The test passes locally but fails in CI: Check CI logs, base URL, environment variables, browser differences, and test data setup. Look for dependence on test order, shared accounts, or leftover state. Re-run the test in isolation and in the same mode used by CI before changing assertions.

The assistant proposes code that does not compile or fit the project: Compare it with the installed Cypress setup and existing examples. Ask for a minimal correction using the exact error and relevant configuration, with secrets removed. If the answer remains uncertain, consult the project documentation or maintainers rather than adding unexplained dependencies.

Frequently Asked Questions

Can AI write Cypress tests without seeing my application?
It can draft a template, but it cannot reliably know your selectors, routes, data, or setup. Supply those details and verify the result in the app.

Should I let an AI assistant run tests or edit files?
Only if the tool and your organization allow it, and you review its actions. Start by generating code for inspection; do not grant access to secrets or production systems unnecessarily.

Can AI-generated tests replace manual testing?
No. They can help automate repeatable checks, but people still need to choose meaningful scenarios, review results, and test behavior that automation does not cover.

How do I keep generated Cypress tests from being flaky?
Use stable selectors, controlled test data, independent setup, and assertions tied to observable states. Avoid fixed sleeps and shared state between tests.

What should I include when asking AI to fix a failing test?
Include the relevant test code, the exact sanitized error, what you expected, what happened, and any pertinent setup. Remove credentials, tokens, and personal information.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.