sodcalculator

10 Tech How-To

Export Cypress Tests from Chrome: What Actually Works

Guide 10-40918 · Updated · Step by step

You cannot directly export a complete Cypress test from Google Chrome: Chrome records browser activity, while Cypress tests are JavaScript code that must be written for the Cypress framework. You can use Chrome to inspect a site, identify selectors, and record a rough interaction outline, then turn that information into a maintainable Cypress test.

What You’ll Need

  • Google Chrome and access to the website you want to test.
  • A Cypress project with Cypress installed, or permission to add Cypress to your existing JavaScript project.
  • A code editor and basic familiarity with JavaScript and HTML selectors.
  • For a protected site, a test account and permission to run automated tests. Avoid using real customer data.

Step-by-Step

  1. Set up or open a Cypress project. If you already have a project, open its folder and check that Cypress is installed. In a new project, create a directory, open a terminal there, run npm init -y, then install Cypress with npm install --save-dev cypress. Open the Cypress app with npx cypress open and follow its prompts to create an end-to-end testing setup. The exact screens can vary by Cypress version.
  2. Choose the test flow before recording anything. Write down the task in plain language, such as “open the sign-in page, enter valid test credentials, and confirm the account page appears.” Decide what visible result proves success. A browser recording is not a substitute for deciding what the test should verify.
  3. Inspect the page in Chrome. Open the website and use Chrome DevTools: right-click an element and choose Inspect, or open DevTools from Chrome’s menu under More tools. In the Elements panel, inspect the relevant buttons, links, fields, and status messages. Look for stable attributes such as an accessible role and name, a label, or an application-specific data-testid.
  4. Use Chrome’s Recorder to capture an interaction outline. Open DevTools, select the Recorder panel, and choose Create a new recording. If Recorder is not visible, open the DevTools panel menu and look for it among the available tools. Give the recording a name, start it, and perform the intended flow in the page. Stop the recording when the steps are complete. Recorder availability and export options can differ between Chrome releases.
  5. Review the recording and export it only as a reference. In Recorder, inspect the recorded steps and remove accidental clicks or unrelated navigation. Use the export or copy option offered by the panel, if available, to save a replayable recording. Chrome Recorder exports are not Cypress test files: the output may use a different format or rely on browser-specific replay tools. Do not rename that file to .cy.js and assume Cypress can run it.
  6. Translate the actions into Cypress commands. Create a test file in the end-to-end spec location configured by your project; common setups use cypress/e2e. Write the flow using Cypress commands such as cy.visit(), cy.get(), and cy.contains(). For example:
    describe('Sign-in flow', () => {
      it('opens the account page after sign-in', () => {
        cy.visit('/login')
        cy.get('[data-testid="email"]').type('test@example.com')
        cy.get('[data-testid="password"]').type('test-password')
        cy.get('[data-testid="sign-in"]').click()
        cy.get('[data-testid="account-page"]').should('be.visible')
      })
    })

    Replace the example URL, credentials, and selectors with values appropriate for your test environment. Use a safe test account and avoid committing secrets to source control.

  7. Set the application’s base URL where appropriate. Configure the base URL in the Cypress configuration file for your project, then visit a relative path such as /login. Otherwise, use the complete address in cy.visit(). Make sure the application is running and reachable before launching the test.
  8. Run the spec and check each assertion. In the Cypress app, choose the end-to-end testing option and select the spec, or run it from the terminal with npx cypress run. Watch for failed commands and verify that the final assertion checks the intended outcome, not merely that a click occurred.
  9. Improve reliability before keeping the test. Prefer selectors that express user-facing meaning, such as role, label, or visible text, when they are unique and stable. Ask the development team for dedicated test attributes when necessary. Remove unnecessary waits and fix the page or test setup if it depends on unpredictable timing.

Common Mistakes

  • Expecting Chrome to produce Cypress code. Chrome Recorder captures browser actions, but Cypress has its own test runner and command API. Translate the intent rather than treating a recording export as a finished spec.
  • Using fragile selectors. Long CSS paths, generated class names, and selectors based on page layout can break after harmless design changes. Prefer accessible labels, roles, stable text, or test-specific attributes.
  • Testing actions without outcomes. A test that clicks “Sign in” but never checks the resulting page can pass without proving the flow works. Add assertions for a meaningful visible result.
  • Leaving real credentials in the spec. Use dedicated test accounts and the project’s approved secret-handling approach. Do not put real passwords or personal data in source-controlled files.
  • Copying the wrong URL or environment. A local development address, staging site, and production site are not interchangeable. Confirm the target environment before running a test that changes data.

Tips

  • Keep each test focused on one user outcome; smaller tests are easier to diagnose.
  • Use Chrome DevTools to check accessible names and labels, not just the visual appearance of controls.
  • Use Cypress’s built-in retry behavior and assertions instead of adding fixed delays such as cy.wait(5000).
  • Test repeatable setup and cleanup where the application supports it, so the test does not depend on a particular previous browser session.
  • Keep recordings as temporary investigation notes. Maintain the Cypress spec as the source of truth for automated test behavior.

Troubleshooting

Recorder is missing: Open the DevTools panel menu and check the available tools. If it is not listed, update Chrome through its normal update process or proceed by inspecting elements manually; Recorder is optional.

The recording will not export or replay: Check the Recorder panel’s current options and the format it provides. Treat the recording as a Chrome-specific artifact, not a Cypress import. You can still use its step list to write the Cypress spec by hand.

Cypress cannot find an element: Confirm the page has loaded, inspect the element again, and check for a changed label, selector, or frame. If the element is inside an iframe or a separate browser context, the test may need a different approach; Chrome’s recorded click alone does not guarantee Cypress can access it.

The test visits the wrong address: Check the Cypress configuration’s base URL and the value passed to cy.visit(). Verify the application is running at that address and that the test is intended for that environment.

The test passes locally but fails intermittently: Look for unstable selectors, network-dependent state, or assumptions about existing data. Replace fixed waits with checks for a specific page state, and make test data and setup repeatable.

Frequently Asked Questions

Can Chrome export a test directly as a Cypress spec?
No. Chrome Recorder can capture and replay browser interactions, but its recording is not a native Cypress spec. Convert the steps into Cypress commands and add assertions.

Where do Cypress test files go?
Use the end-to-end spec folder configured for your project. A common default is cypress/e2e, but check the Cypress configuration if your project uses a different location.

Can I use Chrome Recorder without installing Cypress?
Yes. Recorder is a Chrome DevTools feature. You need Cypress installed only to create and run Cypress tests.

Will a recorded test work on every browser?
Not necessarily. A Chrome recording may use Chrome-specific behavior, and a Cypress test can also behave differently across browsers. Run the Cypress spec in each browser your project needs to support.

Should I use the exact text or selector from the recording?
Only if it is stable and identifies the intended element. Check the page’s labels and attributes, and choose a selector that is unlikely to change during routine design updates.

Can Cypress test a site that requires a login?
Yes, when you have authorized access and a suitable test account. Keep credentials out of committed test files and follow your project’s approved method for managing secrets.

Related

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →