cy visit failed trying to load

Error Messages

• No tests found
• We found an error preparing your test file
• Support file missing or invalid
• Error Loading Config
• Cypress cannot execute commands outside a running test
• cy...() failed because the page updated
• cy...() failed because the element cannot be interacted with
• cy...() failed because the element is currently animating
• The test has finished but Cypress still has commands in its queue
• cy.visit() failed because you are attempting to visit a second unique domain
• cy.visit() failed because you are attempting to visit a different origin domain
• cy.visit() succeeded, but commands are timing out
• Cypress.addParentCommand() / Cypress.addDualCommand() / Cypress.addChildCommand() has been removed and replaced by Cypress.Commands.add()
• Cypress detected that you invoked one or more cy commands in a custom command but returned a different value.
• Cypress detected that you invoked one or more cy commands but returned a different value.
• Cypress detected that you returned a promise from a command while also invoking one or more cy commands in that promise.
• Cypress detected that you returned a promise in a test, but also invoked one or more cy commands inside of that promise.
• Cypress detected that you returned a promise in a test, but also invoked a done callback.
• CypressError: Timed out retrying: Expected to find element: ‘…’, but never found it. Queried from element: <…>
• You passed the --record flag but did not provide us your Record Key.
• The cypress ci command has been deprecated
• A Cached Cypress Binary Could not be found
• Incorrect usage of --ci-build-id flag
• The --ci-build-id , --group , --tag , --parallel , or --auto-cancel-after-failures flags can only be used when recording
• We could not determine a unique CI build ID
• Group name has already been used for this run
• Cannot parallelize tests across environments
• Cannot parallelize tests in this group
• Run must pass --parallel flag
• Cannot parallelize tests on a stale run
• Run is not accepting any new groups
• The Cypress App could not be unzipped. This is most likely because the maximum path length is being exceeded on your system.
• error: unknown option: --auto-cancel-after-failures
• --auto-cancel-after-failures must be a integer or false
• --auto-cancel-after-failures passed without a Business or Enterprise Cloud account
• You passed the --auto-cancel-after-failures flag for a run that is already in progress
• Cypress detected a cross-origin error happened on page load
• Cypress detected that an uncaught error was thrown from a cross-origin script.
• The browser process running your tests just exited unexpectedly
• Whoops, we can't run your tests
• Cannot connect to API server
• Cypress detected policy settings on your computer that may cause issues
• Uncaught exceptions from your application

Test File Errors ​

No tests found ​.

This message means that Cypress was unable to find tests in the specified file. You'll likely get this message if you have an empty test file and have not yet written any tests.

We found an error preparing your test file ​

This message means that Cypress encountered an error when compiling and/or bundling your test file. Cypress automatically compiles and bundles your test code so you can use ES2015, CoffeeScript, modules, etc.

You'll typically receive this message due to: ​

• The file not existing
• A syntax error in the file or one of its dependencies
• A missing dependency

When the error is fixed in your test file, your tests will automatically re-run.

Support File Errors ​

Support file missing or invalid ​.

The supportFolder option was removed from Cypress in version 0.18.0 and was replaced by module support and the supportFile configuration option.

Cypress used to automatically include any scripts in the supportFolder before your test files. However, automatically including all the files in a certain directory is somewhat magical and unintuitive, and requires creating globals for the purpose of utility functions.

Error Loading Config ​

The supportFile configuration option was removed from the root configutation object in Cypress version 10.0.0 . Instead, it must be added within each testing type's configuration object as a separate property if you would like to use a file other than the default supportFile configuration.

Use modules for utility functions ​

Cypress supports both ES2015 modules and CommonJS modules. You can import/require npm modules as well as local modules:

Use supportFile to load scripts before your test code ​

It's still useful to load a setup file before your test code. If you are setting Cypress defaults or utilizing custom Cypress commands, instead of needing to import/require those defaults/commands in every test file, you can use the supportFile configuration option within each testing type's configuration object.

⚠️ For a given testing type, multiple matching supportFile files will result in an error when Cypress loads.

Just like with your test files, the supportFile can use ES2015+, TypeScript or CoffeeScript and modules, so you can import/require other files as needed.

Command Errors ​

Cypress cannot execute commands outside a running test ​.

This message means you tried to execute one or more Cypress commands outside of a currently running test. Cypress has to be able to associate commands to a specific test.

Typically this happens accidentally, like in the following situation.

Move those Cypress commands into an it(...) block and everything will work correctly.

If you are purposefully writing commands outside of a test, there is probably a better way to accomplish what you're trying to do. Read through the Examples or check out our Support channels for more troubleshooting resources.

cy...() failed because the page updated ​

Getting this error means you've tried to interact with a "dead" DOM element - meaning the current subject has been removed from the DOM.

Cypress errors because after a command, the subject becomes 'fixed' to a specific element - since it can't retry commands, if the element becomes detached from the page, we can't assert or interact on it.

Let's take a look at an example below.

Application HTML ​

Application javascript ​, test code causing error ​.

We've programmed our application above so that as soon as the click event happens, the button is removed from the DOM. When Cypress begins processing the next query ( .parent() ) in the test above, it detects that the yielded subject (the original button) is detached from the DOM and throws the error.

Fortunately, the error tells us exactly what to do:

You can typically solve this by breaking up a chain.

Fixed Test Code ​

The above example is an oversimplification, but a representative one. In modern JavaScript frameworks, DOM elements are regularly re-rendered - meaning that the old element is thrown away and a new one is put in its place. Because this happens so fast, it may appear as if nothing has visibly changed to the user. But if you are in the middle of executing test commands, it's possible the element you're interacting with has become "dead". To deal with this situation you must:

• Always start a new chain after each command .
• Use Cypress queries to locate elements on the page, rather than using specific HTML elements as your subject

Queries ( .get() , .as() and .parent() , for example) and assertions ( .should() , .and() ) are safe to chain off of. Commands (such as .click() ) are not.

cy...() failed because the element cannot be interacted with ​

You may see a variation of this message for 4 different reasons:

• The element is not visible
• The element is being covered by another element
• The element's center is hidden from view
• The element is disabled

Cypress runs several calculations to ensure an element can actually be interacted with like a real user would. If you're seeing this error, you may need to guard your commands (due to a timing or an animation issue).

There have been situations where Cypress does not correctly allow you to interact with an element that should be interactable. If that's the case, open an issue .

If you'd like to override these built-in checks, provide the {force: true} option to the action itself. Refer to each command for their available options, additional use cases, and argument usage.

Ignore built-in error checking ​

Be careful with this option. It's possible to force your tests to pass when the element is actually not interactable in your application.

cy...() failed because the element is currently animating ​

By default Cypress detects if an element you're trying to interact with is animating. This check ensures that an element is not animating too quickly for a real user to interact with the element. This also prevents some edge cases where actions, such as .type() or .click() , happened too fast during a transition.

Cypress will continuously attempt to interact with the element until it eventually times out. If you'd like to force Cypress to interact with the element there are a few options:

• Pass {force: true} . This disables all error checking
• Pass {waitForAnimations: false} to disable animation error checking
• Pass {animationDistanceThreshold: 20} to decrease the sensitivity of detecting if an element is animating. By increasing the threshold this enables your element to move farther on the page without causing Cypress to continuously retry.

You can globally disable animation error checking, or increase the threshold by modifying the Cypress configuration .

Cypress configuration file ​

• cypress.config.js
• cypress.config.ts

The test has finished but Cypress still has commands in its queue ​

Let's examine several different ways you may get this error message. In every situation, you'll need to change something in your test code to prevent the error.

Several of these tests are dependent on race conditions. You may have to run these tests multiple times before they will actually fail. You can also try tweaking some of the delays.

Short Example ​

This first test below will pass and shows you that Cypress tries to prevent leaving commands behind in the queue in every test.

Even though we return a string in our test, Cypress automatically figures out that you've queued commands above and does not end the test until all cy commands have finished.

The example below will fail because you've forcibly terminated the test early with mocha's done .

Complex Async Example ​

What's happening in this example is that because we have NOT told Mocha this is an asynchronous test, this test will pass immediately then move onto the next test. Then, when the setTimeout callback function runs, new commands will get queued on the wrong test. Cypress will detect this and fail the next test.

The correct way to write the above test code is using Mocha's done to signify it is asynchronous.

Complex Promise Example ​

In the example below, we forget to return the Promise in our test. This means the test passes synchronously but our Promise resolves in the next test. This also causes the commands to be queued on the wrong test. We will get the error in the next test that Cypress detected it had commands in its command queue.

The correct way to write the above test code would be to return our Promise :

cy.visit() failed because you are attempting to visit a second unique domain ​

This error only pertains to Cypress version v11.0.0 and under. As of Cypress v12.0.0 , users can navigate to multiple domains in a single test.

See our Web Security documentation.

cy.visit() failed because you are attempting to visit a different origin domain ​

Two URLs have the same origin if the protocol , port (if specified), and host are the same for both. You can only visit domains that are of the same-origin within a single test. You can read more about same-origin policy in general here .

You can visit urls that are of different origin across different tests, so you may consider splitting your cy.visit() of different origin domains into separate tests.

See our Web Security documentation for more information and workarounds.

cy.visit() succeeded, but commands are timing out ​

As of Cypress v12.0.0 , users can navigate to multiple domains in a single test. The following test will succeed as-is:

However, when the newly visited URL is not considered the same superdomain, the cy.origin() command must be used to interact with the newly visited domain. The following test is incorrect:

And will result in the following error:

In order to fix this, our cy.get() command must be wrapped with the cy.origin() command, like so:

Cypress.addParentCommand() / Cypress.addDualCommand() / Cypress.addChildCommand() has been removed and replaced by Cypress.Commands.add() ​

In version 0.20.0 , we removed the commands for adding custom commands and replaced them with, what we believe to be, a simpler interface.

Now you can create parent, dual, and child commands using the same Cypress.Commands.add() command.

Please read our new documentation on writing custom commands .

Cypress detected that you invoked one or more cy commands in a custom command but returned a different value. ​

Because cy commands are asynchronous and are queued to be run later, it doesn't make sense to return anything else.

For convenience, you can also omit any return value or return undefined and Cypress will not error.

In versions before 0.20.0 of Cypress we automatically detected this and forced the cy commands to be returned. To make things less magical and clearer, we are now throwing an error.

Cypress detected that you invoked one or more cy commands but returned a different value. ​

Cypress detected that you returned a promise from a command while also invoking one or more cy commands in that promise. ​.

Because Cypress commands are already promise-like, you don't need to wrap them or return your own promise.

Cypress will resolve your command with whatever the final Cypress command yields.

The reason this is an error instead of a warning is because Cypress internally queues commands serially whereas Promises execute as soon as they are invoked. Attempting to reconcile this would prevent Cypress from ever resolving.

Cypress detected that you returned a promise in a test, but also invoked one or more cy commands inside of that promise. ​

While this works in practice, it's often indicative of an anti-pattern. You almost never need to return both a promise and also invoke cy commands.

cy commands themselves are already promise like, and you can likely avoid the use of the separate Promise.

Cypress detected that you returned a promise in a test, but also invoked a done callback. ​

The version of Mocha was upgraded with Cypress 4.0. Mocha 3+ no longer allows returning a promise and invoking a done callback. Read more about it in the 4.0 migration guide .

CypressError: Timed out retrying: Expected to find element: ‘…’, but never found it. Queried from element: <…> ​

If you get this error in a case where the element is definitely visible in the DOM, your document might contain malformed HTML. In such cases, document.querySelector() will not find any elements that appear after the point where the HTML is malformed. Even if you feel certain your HTML is not malformed anywhere, check it anyway (line by line in the dev tools). Especially if you've exhausted all other possibilities.

CLI Errors ​

You passed the --record flag but did not provide us your record key. ​.

You may receive this error when trying to run Cypress tests in Continuous Integration . This means that you did not pass a specific record key to: cypress run --record .

Since no record key was passed, Cypress checks for any environment variable with the name CYPRESS_RECORD_KEY . In this case, that was also not found.

You can get your project's record key by locating it in your settings tab in the Cypress app or in Cypress Cloud .

You will want to then add the key to your config file or as an environment variable .

The cypress ci command has been deprecated ​

As of version 0.19.0 and CLI versions 0.13.0 , the cypress ci command has been deprecated. We did this to make it clearer what the difference was between a regular test run and a recorded test run .

Previously to record runs you had the environment variable: CYPRESS_CI_KEY or you wrote:

You need to rewrite this as:

If you were using the environment variable CYPRESS_CI_KEY , rename it to CYPRESS_RECORD_KEY .

You can now run and omit the --key flag:

We will automatically apply the record key environment variable.

A Cached Cypress Binary Could not be found ​

This error occurs in CI when using cypress run without a valid Cypress binary cache installed on the system (on linux that's ~/.cache/Cypress ).

To fix this error, follow instructions on caching the cypress binary in CI , then bump the version of your CI cache to ensure a clean build.

Incorrect usage of --ci-build-id flag ​

You passed the --ci-build-id flag but did not provide either a --group or --parallel flag.

The --ci-build-id flag is used to either group or parallelize multiple runs together.

Check out our guide on parallelizing runs and when to use the --ci-build-id option.

The --ci-build-id , --group , --tag , --parallel , or --auto-cancel-after-failures flags can only be used when recording ​

You passed the --ci-build-id , --group , --tag , --parallel , or --auto-cancel-after-failures flag without also passing the --record flag.

These flags can only be used when recording to Cypress Cloud .

Please review our parallelization documentation to learn more.

We could not determine a unique CI build ID ​

You passed the --group or --parallel flag but we could not automatically determine or generate a ciBuildId .

In order to use either of these parameters a ciBuildId must be determined.

The ciBuildId is automatically detected if you are running Cypress in most CI providers . Please review the natively recognized environment variables for your CI provider.

You can avoid this check in the future by passing an ID to the --ci-build-id flag manually.

Group name has already been used for this run ​

You passed the --group flag, but this group name has already been used for this run.

If you are trying to parallelize this run, then also pass the --parallel flag, else pass a different group name.

Please review grouping test runs documentation to learn more.

Cannot parallelize tests across environments ​

You passed the --parallel flag, but we do not parallelize tests across different environments.

This machine is sending different environment parameters than the first machine that started this parallel run.

In order to run in parallel mode each machine must send identical environment parameters such as:

• Operation system name
• Operating system version
• Browser name
• Major browser version

Cannot parallelize tests in this group ​

You passed the --parallel flag, but this run group was originally created without the --parallel flag.

You cannot use the --parallel flag with this group.

Please review our grouping test runs documentation to learn more.

Run must pass --parallel flag ​

You did not pass the --parallel flag, but this run's group was originally created with the --parallel flag.

You must use the --parallel flag with this group.

Cannot parallelize tests on a stale run ​

This error is thrown when you are attempting to pass the --parallel flag to a run that Cypress detected was completed over 24 hours ago.

In order to uniquely identify each run during cypress run , Cypress attempts to read a unique identifier from your CI provider as described in our parallelization doc .

You may encounter this error if Cypress is detecting the exact same CI Build ID matching a previous CI Build ID in a run that was completed over 24 hours ago. You cannot run tests on a run that has been complete for that long. ​ ​You can see the CI Build ID that is detected for each completed run by looking at the details section at the top of your run in Cypress Cloud . ​ ​You can generate and pass in your own unique CI Build ID per run as described here .

Please also review our parallelization documentation to learn more.

Run is not accepting any new groups ​

The run you are attempting access to is already complete and will not accept new groups.

When a run finishes all of its groups, it waits for a configurable set of time, a run completion delay , before completing. All cypress run calls with any new groups must be executed during that time period.

Troubleshooting ​

• If you are passing --ci-build-id , make sure it is generating a unique value for the run. If it is not unique and matches a previous run, you may see this error.
• If you are running cypress run calls in parallel and they are not completing within the default 60 second run completion delay, you can increase this delay. See instructions .

The Cypress App could not be unzipped. This is most likely because the maximum path length is being exceeded on your system. ​

When Cypress is installed, it unzips to the designated cache location on your computer. This error means that Cypress detected that it has exceeded the maximum path length while unzipping Cypress.

This is common on Windows, where the maximum path length used to be 260 characters.

To fix this error, enable "long paths" on your Windows system:

• Go to the Start Menu, and right click on PowerShell. Select "Run as administrator."
• Run this command:
• Restart your computer.

This should get rid of the error. If you are still receiving this error, please search for an open issue or open a new one .

If you do not have Powershell available, you can also make this change via regedit or gpedit. See Microsoft's documentation for details.

error: unknown option: --auto-cancel-after-failures ​

The --auto-cancel-after-failures flag is only available in Cypress 12.6.0 and later, and must be used with the cypress run command.

--auto-cancel-after-failures must be a integer or false ​

You passed in an invalid value for the --auto-cancel-after-failures flag. It must be an integer or false.

--auto-cancel-after-failures passed without a Business or Enterprise Cloud account ​

Auto Cancellation is not included in your current billing plan. To enable this service, please visit your billing and upgrade to another plan with Auto Cancellation.

https://www.cypress.io/pricing/

You passed the --auto-cancel-after-failures flag for a run that is already in progress ​

You passed the --auto-cancel-after-failures flag, but this run originally started with a different value on this --auto-cancel-after-failures flag.

The first setting of --auto-cancel-after-failures for any given run takes precedent.

Page Load Errors ​

Cypress detected a cross-origin error happened on page load ​.

For a more thorough explanation of Cypress's Web Security model, please read our dedicated guide to it .

This error means that your application navigated to a superdomain that Cypress was not bound to. Initially when you cy.visit() , Cypress changes the browser's URL to match the url passed to cy.visit() . This enables Cypress to communicate with your application to bypass all same-origin security policies among other things.

When your application navigates to a superdomain outside of the current origin-policy, Cypress is unable to communicate with it, and thus fails.

There are a few workarounds to these common situations: ​

Don't click <a> links in your tests that navigate outside of your application. Likely this isn't worth testing anyway. You should ask yourself: What's the point of clicking and going to another app? Likely all you care about is that the href attribute matches what you expect. So make an assertion about that. You can see more strategies on testing anchor links in our "Tab Handling and Links" example recipe .

You are testing a page that uses Single sign-on (SSO). In this case your web server is likely redirecting you between superdomains, so you receive this error message. You can likely get around this redirect problem by using cy.request() to manually handle the session yourself.

If you find yourself stuck and can't work around these issues you can set chromeWebSecurity to false in your Cypress configuration when running in Chrome family browsers (this setting will not work in other browsers). Before doing so you should really understand and read about the reasoning here .

Cypress detected that an uncaught error was thrown from a cross-origin script. ​

Check your Developer Tools Console for the actual error - it should be printed there.

It's possible to enable debugging these scripts by adding the crossorigin attribute and setting a CORS header.

Browser Errors ​

The browser process running your tests just exited unexpectedly ​.

This error can occur whenever Cypress detects that the launched browser has exited or crashed before the tests could finish running.

This can happen for a number of reasons, including:

• The browser was exited manually, by clicking the "Quit" button or otherwise
• Your test suite or application under test is starving the browser of resources.
• Cypress is running in a memory-starved environment
• The browser is testing a memory-heavy application
• There are problems with the GPU / GPU drivers
• There is a bug in the browser involving memory management
• There is a memory leak in Cypress

For Chromium-based browsers, you can try enabling experimentalMemoryManagement .

If you are running in open mode, you can also try lowering numTestsKeptInMemory .

If the browser running Cypress tests crashes, Cypress will abort any remaining tests and print out this error.

Cypress App errors ​

Whoops, we can't run your tests ​.

This error happens when Cypress detects that the browser automation is not connected, or that Cypress's internal proxy is being bypassed. This is caused by one of the following:

A policy setting blocks the Cypress proxy server or browser extension

• See Cypress detected policy settings on your computer that may cause issues .

The --proxy-server or --load-extension arguments have been changed

• When adding a plugin with the Browser Launch API , it's possible for a necessary command-line argument to be changed. If you're running into this error, you can troubleshoot by inspecting args before and after the plugin runs, either by using console.log() or by printing DEBUG logs with DEBUG=cypress:server:plugins,cypress:server:plugins:* .

You visit the Cypress proxy URL outside of a Cypress browser.

• Don't copy the URL you see when launching a Cypress browser from the Cypress App and open it in a non-Cypress browser. If you want to run your tests in a different browser, follow the instructions in the Cross Browser Testing guide.

Cannot connect to API server ​

Logging in, viewing runs, and setting up new projects to record requires connecting to an external API server. This error displays when we failed to connect to the API server.

This error likely appeared because:

• You do not have internet. Please ensure you have connectivity then try again.
• You are a developer that has forked our codebase and do not have access to run our API locally. Please read more about this in our contributing doc .

Cypress detected policy settings on your computer that may cause issues ​

When Cypress launches Chrome, it attempts to launch it with a custom proxy server and browser extension. Certain group policies (GPOs) on Windows can prevent this from working as intended, which can cause tests to break.

If your administrator has set any of the following Chrome GPOs, it can prevent your tests from running in Chrome:

• Proxy policies: ProxySettings, ProxyMode, ProxyServerMode, ProxyServer, ProxyPacUrl, ProxyBypassList
• Extension policies: ExtensionInstallBlacklist, ExtensionInstallWhitelist, ExtensionInstallForcelist, ExtensionInstallSources, ExtensionAllowedTypes, ExtensionAllowInsecureUpdates, ExtensionSettings, UninstallBlacklistedExtensions

Here are some potential workarounds:

• Ask your administrator to disable these policies so that you can use Cypress with Chrome.
• Use the built-in Electron browser for tests, since it is not affected by these policies. See the guide to launching browsers for more information.
• Try using Chromium instead of Google Chrome for your tests, since it may be unaffected by GPO. You can download the latest Chromium build here.
• Open up Registry Editor by pressing WinKey+R and typing regedit.exe
• HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome
• HKEY_LOCAL_MACHINE\Software\Policies\Google\Chromium
• HKEY_CURRENT_USER\Software\Policies\Google\Chrome
• HKEY_CURRENT_USER\Software\Policies\Google\Chromium
• Delete or rename any policy keys found. Make sure to back up your registry before making any changes.

Uncaught exceptions from your application ​

When Cypress detects an uncaught exception in your application, it will fail the currently running test.

You can turn off this behavior globally or conditionally with the uncaught:exception event. Please see the Catalog of Events for examples.

On a technical note, Cypress considers uncaught exceptions to be any error that is uncaught by your application, whether they are "standard" errors or unhandled promise rejections. If the error triggers the window's global error handler or its unhandledrejection handler, Cypress will detect it and fail the test.

Blog Education: Tutorials

Cypress for Beginners: 5 Commands to Kickstart Your Testing Journey

September 9, 2024

By Farah Shalwani

To any newcomers of testing: Welcome to the exciting world of Cypress! If you're new to web application testing, Cypress is a fantastic framework that makes writing and running tests a breeze. To start your journey, let's explore five essential Cypress commands that will quickly become your testing arsenal.

1. Visit Your Test Subject: cy.visit()

The first step in any Cypress end-to-end test is to tell it where to start – enter cy.visit() . This command loads the web page you want to interact with and test. Think of it as the starting line of your test race. Whether it's a live website or a simple HTML file on your computer, cy.visit() is your trusty navigator.

There's more to cy.visit() than meets the eye. You can customize its behavior:

Set a default base URL in your [Cypress configuration](https://docs.cypress.io/guides/references/configuration) to avoid typing the full address every time.

Here's how your tests would look after the baseUrl is set:

By mastering cy.visit() , you'll be able to control the starting point of your tests and ensure your virtual user lands on the right page before you put it through its paces. 

2. Grab Elements on the Page: cy.get()

Now that you've landed on your webpage, it's time to interact with it. This is where cy.get() shines. It's your way of telling Cypress, "Hey, find this specific element on the page so I can work with it." Think of it like playing a game of "I Spy." You describe what you're looking for, and Cypress locates it for you. Here are the common ways to select elements:

CSS Selectors: These are like the addresses for elements on your page. You can target them by their tag name (e.g., button, div), class name (e.g., .my-button), ID (e.g., #submit), or any combination of these. One reliable way to select elements is by using data attributes. These are custom attributes you add to your HTML, like data-cy="login-button". This way, even if your CSS changes, your tests remain stable.

Here's how you'd use cy.get() with some selectors:

cy.get() is incredibly versatile. You can also chain it with other commands to perform more specific queries or actions on the elements you find. For example:

By mastering cy.get() , you'll be able to target and manipulate elements on your web page, making your tests truly interactive.

3. Click Away: cy.click()

Once you've used cy.get() to grab hold of your target element, it's time to unleash the power of interaction with cy.click() . This command does exactly what it says – it simulates a real user clicking on the selected element.  Whether it's a button that triggers an action, a link that takes you to a new page, or any other clickable element, cy.click() is your virtual fingertip.

The basic usage is beautifully simple:

But cy.click() has a few tricks up its sleeve:

Multiple Clicks: Want to click multiple elements? Use the multiple: true option:

Forced clicks: sometimes, elements might be visually hidden or obstructed. no problem cy.click() can push through with the force: true option:, click positions: you can even control where on the element the click happens (top left, center, bottom right, etc.):.

With cy.click() , you can mimic a wide range of user interactions, from simple button clicks to complex navigation sequences. This makes your Cypress tests feel like a real user is exploring your application, ensuring a robust and comprehensive testing experience.

4. Type Like a User: .type()

Let's face it, most web applications involve some form of text input – filling out forms, searching for products, writing comments, and so on.  Cypress has you covered for all of these scenarios with the .type() command. This command emulates a user typing into a type-able element. 

Imagine you have a login form with an email field:

This simple command finds the email input field and types " [email protected] " into it. But .type() can do much more:

Special Characters: Want to simulate typing symbols or key combinations? Use curly braces to enclose special character sequences:

Delayed typing: by default, .type() types each character every 10ms to simulate how a user might type. you can slow or speed this up by using the delay option:, typing events: cypress also triggers events like keydown , keypress , and keyup as it types, making your tests even more accurate..

With .type() , you can automate the input of any kind of text, making your Cypress tests comprehensive and user-friendly.

5. Check Your Work: .should()

After you've navigated to your web page, selected elements, clicked buttons, and filled out forms, it's time for the moment of truth: verifying that your application is behaving as expected. That's where .should() steps in. This command is your quality control inspector, allowing you to make assertions about the state of your web page.

Think of assertions as questions you ask Cypress about the elements on your page:

"Is this button visible?"

"Does this heading contain the correct text?"

"Does this element have a specific CSS class?"

With .should() , you can pose these questions and Cypress will give you a definitive answer – either the assertion passes (the condition is true) or it fails (the condition is not met). Here's the basic structure:

In this example, we're first selecting the `<h1>` element and then using .should() to assert that it contains the specified text. Cypress provides a wide range of built-in assertions you can use:

Existence: exist , not.exist

Visibility: be.visible , be.hidden, content: contain , have.text , have.value, classes and attributes: have.class , have.attr, length and count: have.length , have.length.greaterthan.

You can even combine multiple assertions:

.should() not only helps you catch bugs but also makes your tests more readable and self-documenting. By clearly stating your expectations, you create tests that are easy to understand and maintain.

Bonus Tip: Pause and Synchronize with cy.wait()

While cy.visit() , cy.get() , .click() , .type() , and .should() are the bread and butter of Cypress, the cy.wait() command is your secret weapon for handling the asynchronous nature of web applications. 

Many web apps make requests to servers to fetch data or update information. cy.wait() can wait for these requests to complete before proceeding:

By intercepting requests and waiting for their responses, you can ensure your tests are synchronized with your application's data flow.

Important Considerations

Cypress already has built-in retry mechanisms for most commands. For example, cy.get() will automatically retry until the element is found or until the default timeout has passed.

Explore the cy.intercept() command to gain more control over network requests and how you wait for them. By incorporating cy.wait() judiciously into your tests, you can handle asynchronous behavior gracefully and ensure that your Cypress tests are reliable and robust.

Remember, these are just the building blocks.  Cypress has a rich set of commands to explore. The best way to learn is by doing, so try building a small test suite using these five commands. Don't hesitate to dive into the Cypress documentation for more details and discover even more powerful features. 

Happy testing!

Visit a remote URL.

Best Practice We recommend setting a baseUrl when using cy.visit() . Read about best practices here.

Correct Usage

url (String)

The URL to visit.

Cypress will prefix the URL with the baseUrl configured in your global configuration if set.

If the baseUrl has not been set, you will need to specify a fully qualified URL or Cypress will attempt to act as your web server. See the prefixes notes for more details.

Note: visiting a new domain requires the Test Runner window to reload. You cannot visit different super domains in a single test.

options (Object)

Pass in an options object to control the behavior of cy.visit() .

By default, the cy.visit() commands' will use the pageLoadTimeout and baseUrl set globally in your configuration .

You can also set all cy.visit() commands' pageLoadTimeout and baseUrl globally in configuration .

• cy.visit() 'yields the window object after the page finishes loading'

Let's confirm the window.navigator.language after visiting the site:

Visit a local server running on http://localhost:8000

cy.visit() resolves when the remote page fires its load event.

Change the default timeout

Overrides the pageLoadTimeout set globally in your configuration for this page load.

Add basic auth headers

Cypress will automatically apply the right authorization headers if you're attempting to visit an application that requires Basic Authentication .

Provide the username and password in the auth object. Then all subsequent requests matching the origin you're testing will have these attached at the network level.

You can also provide the username and password directly in the URL.

Cypress will automatically attach this header at the network proxy level, outside of the browser. Therefore you will not see this header in the Dev Tools.

Provide an onBeforeLoad callback function

onBeforeLoad is called as soon as possible, before your page has loaded all of its resources. Your scripts will not be ready at this point, but it's a great hook to potentially manipulate the page.

Check out our example recipes using cy.visit() 's onBeforeLoad option to: Bootstrapping your App Set a token to localStorage for login during Single Sign On Stub window.fetch

Provide an onLoad callback function

onLoad is called once your page has fired its load event. All of the scripts, stylesheets, html and other resources are guaranteed to be available at this point.

Add query parameters

You can provide query parameters as an object to cy.visit() by passing qs to options .

The parameters passed to qs will be merged into existing query parameters on the url .

Submit a form

To send a request that looks like a user submitting an HTML form, use a POST method with a body containing the form values:

Visit is automatically prefixed with baseUrl

Cypress will prefix the URL with the baseUrl if it has been set. We recommending configuring the baseUrl in the your configuration file ( cypress.json by default) to prevent repeating yourself in every cy.visit() command.

If you would like to visit a different host when the baseUrl has been set, provide the fully qualified URL you would like to go to.

Visit local files

Cypress will automatically attempt to serve your files if you don't provide a host and the baseUrl is not defined . The path should be relative to your project's root folder (where the cypress.json file is generated by default).

Having Cypress serve your files is useful in smaller projects and example apps, but isn't recommended for production apps. It is always better to run your own server and provide the URL to Cypress.

Visit local file when baseUrl is set

If you have baseUrl set, but need to visit a local file in a single test or a group of tests, set the baseUrl to null by using a test configuration . Given our cypress.json file:

The first test visits the baseUrl , while the second test visits the local file.

Visit will automatically follow redirects

Protocol can be omitted from common hosts.

Cypress automatically prepends the http:// protocol to common hosts. If you're not using one of these 3 hosts, then make sure to provide the protocol.

Visit will always yield the remote page's window object when it resolves

Trying to change the User-Agent ? You can set the userAgent as a configuration value in your configuration file.

Prevent requests before a remote page initially loads

One common scenario Cypress supports is visiting a remote page and also preventing any Ajax requests from immediately going out.

You may think this works:

But if your app makes a request upon being initialized, the above code will not work . cy.visit() will resolve once its load event fires. The cy.intercept() command is not processed until after cy.visit() resolves.

Many applications will have already begun routing, initialization, and requests by the time the cy.visit() in the above code resolves. Therefore creating a cy.intercept() route will happen too late, and Cypress will not process the requests.

Luckily Cypress supports this use case. Reverse the order of the commands:

Cypress will automatically apply the routes to the very next cy.visit() and does so immediately before any of your application code runs.

Requirements

• cy.visit() requires being chained off of cy .
• cy.visit() requires the response to be content-type: text/html .
• cy.visit() requires the response code to be 2xx after following redirects.
• cy.visit() requires the load load event to eventually fire.
• cy.visit() will automatically wait for assertions you have chained to pass
• cy.visit() can time out waiting for the page to fire its load event.
• cy.visit() can time out waiting for assertions you've added to pass.

Command Log

Visit example application in a beforeEach

The commands above will display in the Command Log as:

When clicking on visit within the command log, the console outputs the following:

• cy.reload()
• cy.request()
• Recipe: Bootstrapping your App
• Recipe: Logging In - Single Sign on
• Recipe: Stubbing window.fetch

© 2017 Cypress.io Licensed under the MIT License. https://docs.cypress.io/api/commands/visit

• After Run API
• After Screenshot API
• After Spec API
• Before Run API
• Before Spec API
• Browser Launch API
• Catalog of Events

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cy.visit() failed trying to load https://example.cypress.io/，but I can open it with my browser #7100

debbyzang commented Apr 22, 2020 • edited by jennifer-shehane Loading

jennifer-shehane commented Apr 22, 2020

Sorry, something went wrong.

eternalmatt commented Sep 4, 2020 • edited by jennifer-shehane Loading

Jennifer-shehane commented oct 20, 2020.

• 👍 1 reaction

vpvikash commented Jun 25, 2021

No branches or pull requests