cypress cy.visit not working

8 common mistakes in Cypress (and how to avoid them)

This is a blog post made from a talk I gave at Front end test fest, so if you want to watch a video about it, feel free to do so on this link .

On my Discord server, I sometimes encounter a common pattern when answering questions. There are certain sets of problems that tend to surface repeatedly and for these, I created this blog post. Let’s jump into them!

#1: Using explicit waiting

This first example feels kinda obvious. Whenever you added an explicit wait to your Cypress test, I believe you had an unsettling feeling about this. But what about the cases when our tests fail because the page is too slow? Feels like using cy.wait() is the way to go.

But this makes our test just sit there and hope that the page will get loaded before the next command. Instead, we can make use of Cypress’ built-in retryability.

So why is this better? Because this way, we will wait maximum 10 seconds for that button to appear. But if the button renders sooner, the test will immediately move on to the next command. This will help you save some time. If you want to read more about this, I recommend checking out my blog on this topic .

#2: Using unreadable selectors

I could write a whole article just on the topic of selectors ( in fact, I did ), since this is one of the most dealt-with topics for testers. Selectors can be the first thing that can give us a clue as to what our test is doing. Because of that, it is worth making them readable.

Cypress has some recommendations as to which selectors should be used. The main purpose of these recommendations is to provide stability for your tests. At the top of the recommendations is to use separate data-* selectors. You should add these to your application.

However (and unfortunately IMHO), testers don’t always have the access to the tested application. This makes selecting elements quite a challenge, especially when the element we are searching for is obscure. Many that find themselves in this situation reach for various strategies for selecting elements.

One of these strategies is using xpath . The big caveat of xpath is that their syntax is very hard to read . By merely looking at your xpath selector, you are not really able to tell what element you are selecting. Moreover, they don’t really add anything to the capabilities of your Cypress tests. Anything xpath can do you can do with Cypress commands, and make it more readable.

#3: Selecting elements improperly

Consider the following scenario. You want to select a card (the white element on the page) and assert its text.

Notice how both of these elements contain the word "bugs" inside. Can you tell which card are we going to select when using this code?

You might be guessing the first one, with the text "triage found bugs". While that may be a good answer it’s not the most precise one. Correctly it is - whichever card will load first.

It is important to remember that whenever a Cypress command finishes doing its job, it will move on to the next command. So once an element is found by the .get( ) command, we will move to the .eq(0)` command. After that, we will move to our assertion that will fail.

You might wonder why Cypress does not retry at this point, but it actually does. Just not the whole chain. By design, .should() command will retry the previous command, but not the whole chain . This is why it is vital to implement a better test design here and add a "guard" for this test. Before we assert the text of our card, we’ll make sure that all cards are present in DOM:

#4: Ignoring requests in your app

Let’s take a look at this code example:

When we open our page, multiple requests get fired. Responses from these requests will get digested by the frontend app and rendered into our page. In this example [data-cy=list] elements get rendered after we get a response from /api/lists endpoint.

But the problem with this test is, that we are not telling Cypress to wait for these requests. Because of this, our test may give us a false positive and pass even if there are lists present in our application.

Cypress will not wait for the requests our application does automatically. We need to define this using the intercept command:

#5: Overlooking DOM re-rendering

Modern web applications send requests all the time to get information from the database and then render them in DOM. In our next example, we are testing a search bar, where each keystroke will send a new request. Each response will make the content on our page re-render. In this test, we want to take a search result and confirm that after we type the word "for", we will see the first item with the text "search for critical bugs". The test code goes like this:

This test will suffer from "element detached from DOM" error. The reason for this is that while still typing, we will first get 2 results, and when we finish, we’ll get just a single result. In a result, our test will go like this:

• "f" key is typed in the search box
• request searching for all items with "f" will fire
• response comes back and app will render two results
• "o" key is typed in the search box
• request searching for all items with "fo" will fire
• "r" key is typed in the search box
• request searching for all items with "for" will fire
• Cypress is done with typing, so it moves to the next command
• Cypress will select [data-cy=result-item] elements and will filter the first one (using .eq(0) ) command
• Cypress will assert that it has the text "search for critical bugs"
• since the text is different, it will run the previous command again ( .eq(0) )
• while Cypress is retrying and going back and forth between .eq(0) and .should() a response from our last request comes back and app will re-render to show single result
• the element that we selected in step 10 is no longer present, so we get an error

Remember, .should() command will make the previous command retry, but not the full chain. This means that our cy.get('[data-cy=result-item]') does not get called again. To fix this problem we can again add a guarding assertion to our code to first make sure we get the proper number of results, and then assert the text of the result.

But what if we cannot assert the number of results? I wrote about this in the past , but in short, the solution is to use .should() command with a callback, something like this:

#6: Creating inefficient command chains

Cypress has a really cool chaining syntax. Each command passes information to the next one, creating a one-way flow of your test scenario. But even these commands have an internal logic inside them. Cypress commands can be either parent, child or dual. This means, that some of our commands will always start a new chain.

Consider this command chain:

The problem with writing a chain like this is not only that it is hard to read, but also that it ignores this parent/child command chaining logic. Every .get() command is actually starting a new chain. This means that our .click().get() chain does not really make sense. Correctly using chains can prevent your Cypress tests from unpredictable behavior and can make them more readable:

#7: Overusing UI

I believe that while writing UI tests, you should use UI as little as possible. This strategy can make your test faster and provide you the same (or bigger) confidence with your app. Let’s say you have a navigation bar with links, that looks like this:

The goal of the test will be to check all the links inside <nav> element, to make sure they are pointing to a live website. The intuitive approach might be using .click() command and then check either location or content of the opened page to see if the page is live.

However, this approach is slow and in fact, can give you false confidence. As I mentioned in one of my previous blogs, this approach can overlook that one of our pages is not live, but returns a 404 error.

Instead of checking your links like this, you can use .request() command to make sure that the page is live:

#8: Repeating the same set of actions

It’s really common to hear that your code should be DRY = don’t repeat yourself. While this is a great principle for your code, it seems like it is slightly ignored during the test run. In an example below, there’s a cy.login() command that will go through the login steps and will be used before every test:

Having this sequence of steps abstracted to a single command is definitely good. It will definitely make our code more "DRY". But as we keep using it in our test, our test execution will go through the same steps over and over, essentially repeating the same set of actions.

With Cypress you can pull up a trick that will help you solve this issue. This set of steps can be cached and reloaded using cy.session() command. This is still in an experimental state, but can be enabled using experimentalSessionAndOrigin: true attribute in your cypress.config.js . You can wrap the sequence in our custom command into .session() function like this:

This will cause to run the sequence in your custom commands just once per spec. But if you want to cache it throughout your whole test run, you can do that by using cypress-data-session plugin . There are a lot more things you can do this, but caching your steps is probably the most valuable one, as it can easily shave off a couple of minutes from the whole test run. This will of course depend on the test itself. In my own tests, where I just ran 4 tests that logged in, I was able to cut the time in half.

Hopefully, this helped. I’m teaching all this and more in my upcoming workshop . Hope to see you there!

Tweet this article

Share on LinkedIn

Edit on GitHub

Table of contents:

Let’s keep in touch.

From time to time I send some useful tips to your inbox and let you know about upcoming events. Sign up if you want to stay in loop.

is required.

I treat your email address like I would my own. That means no ads. Just notifications of when I do cool stuff. Unsubscribe anytime. Click here to read about how I handle your data

A common mistake when using cy.session() (and how to fix it)

February 8, 2023

This is a guest post from Ambassador Filip Hric! Hello, I’m Filip. I teach testers about web development and developers about testing. I have spoken at conferences around the world, created multiple online courses, and host live workshops on e2e testing in Cypress.io. Find everything I do at https://filiphric.com.

In Cypress v12, the cy.session() command was released as generally available. Many teams have already added it to their projects to save minutes from their test runs.

I recently wrote a blogpost on how cy.session() can be used instead of abstracting login logic into a page object. As community members on my Discord implement cy.session() into their projects, I often see one problem pop up repeatedly. Let me give you an example.

Consider this login flow:

By applying the cy.session() API, we can cache the cookies, localStorage and sessionStorage state of our browser for this login flow like this:

There is one small problem with this type of login. As soon as Cypress completes the cy.type() function, it caches our browser state. However, our frontend might still be working on the login flow and some of the authentication data we need has not been set.

Let’s say our application login will send an http request to the server to authenticate the user, and then redirect to a home page, before saving cookies into the browser.

Given the example above, our session will not get properly cached because we didn’t not explicitly tell cy.session() authentication flow is still in progress. The easiest way we can fix that is to add a guarding assertion to our session.

This way we will ensure that Cypress will cache our browser at the right moment. Depending on our application, this might be right after we navigate to a new page or some time later. The exact point will be determined by the application we are testing.

Usually, when making a login action, a server responds with an authorization in the form of a token that gets saved as cookies or some other browser storage. Instead of checking for the location, we can check that storage item. The session might then look something like this:

There is a slight problem with this approach though. The cy.getCookie() command will execute immediately and will not retry. Instead of using cy.getCookie() command we will choose a slightly different approach.

This way we can ensure that we wait the proper time for the application to store our cookies in the browser. After our cookies are saved, we can safely cache our session and use it in our tests.

The validation of a successful login is important for the cy.session() command to work properly. In fact, when using cy.session() you can add the validation as a separate step. This is what the validate() function is for. Let’s see it in action:

In this simple example, cy.session() will work pretty much the same way as before. But there is one upside to this approach. Our validate() function can do more than check the mere presence of the token. Instead, we could check for the validity of the token and make sure it does not expire during, e.g., a longer test run. The validate function can look something like this:

If the cy.request() returns an error code, it will mean that our authorization is no longer valid and we need to log in again. The validate() function will take care of this, and re-run our login flow.

This way we still keep login attempts to minimum, while making sure that the authorization does not expire during the test run.

Remember to always ensure that your cy.session() flow contains a “confirming assertion” that will guard the creation of the session to proper time.

About the Ambassador Program

The Cypress Ambassador program supports the top Cypress advocates around the world. Through this program, Ambassadors are offered speaking opportunities, a personalized hub, and visibility within our extensive network.To learn more about these wonderful ambassadors visit our Official Ambassador webpage.

Cypress Testing: The Guide [2024 Updated]

If you’ve ever struggled with the complexities of traditional testing frameworks like Selenium—setting up drivers, dealing with flaky tests, and waiting forever for things to load—Cypress will feel like a lifesaver.  Why? Because Cypress simplifies your testing process in ways that save both time and energy. Imagine being able to test your web app in real time, automatically waiting for elements to load, and having a robust tool that integrates seamlessly with modern JavaScript frameworks like React and Angular. It’s fast, reliable, and ideal for today’s agile development workflows.  In this guide, we'll show you how to do Cypress testing - everything! From the installation to advanced Cypress testing techniques.

1. What is Cypress?

Technically speaking, Cypress is a modern JavaScript-based end-to-end testing framework designed to run in the browser using Node.js. It was built specifically for testing web applications, with features tailored to frontend developers' needs. But, let’s step out of the tech jargon for a moment.  In simple terms, Cypress helps you see your website through the eyes of your users. It interacts with your app the way a real person would—by clicking buttons, filling out forms, and navigating pages. Whether you're testing how your login form handles incorrect passwords or how fast your shopping cart loads, Cypress is designed to mimic these real-world scenarios​. And the best part? It’s all done in real-time, making the process super interactive.

2. Key Features of Cypress

Let’s dive into what makes Cypress such a powerful tool:

• JavaScript-Based Framework : Cypress is built using JavaScript, which means it’s perfect for developers working in modern web stacks. Most web apps today run on JavaScript, so why not test them in the same language? This eliminates the hassle of dealing with different programming languages or configurations. It’s just JavaScript all the way​.
• Automatic Waiting : This is where Cypress really shines. Say goodbye to those frustrating moments when your test fails because the element you’re trying to interact with hasn’t loaded yet. Cypress automatically waits for elements, animations, and API calls to complete before moving on to the next step in your test​.
• Real-Time Reloading & Time Travel : With Cypress’s Time Travel feature, you can hover over each step of your test and see exactly what happened. Pair that with real-time reloading, where changes to your test file automatically reload the browser, and debugging becomes incredibly intuitive.

3. Setting Up Cypress

Setting up Cypress is surprisingly easy, especially compared to older testing frameworks like Selenium, where multiple configurations are necessary. With Cypress, you can be up and running in just a few steps—no more fumbling around with drivers or complex setups. Let’s break it down.

Step 1: Installing Cypress as a Dev Dependency

Installing Cypress as a dev dependency ensures it’s only used in the development environment and not bundled into your production code. This keeps your production build lightweight and focused on delivering your app’s core functionality, while Cypress stays in your development environment to handle testing.

To do this, open your terminal and make sure you’re in the root directory of the project you want to test. You can do this with the cd command.

Now that you’re in your project directory, install Cypress by running the following command:

This command tells npm to download Cypress and install it as a dev dependency. The --save-dev flag is critical here because it tells npm to add Cypress to the devDependencies section of your package.json file. This ensures that Cypress is only used during development, making it a best practice in modern web development​.

After installation, confirm that Cypress is installed by checking the node_modules directory and ensuring the cypress folder is present. You can also look for Cypress in your package.json under devDependencies .

Step 2: Launching Cypress

Once Cypress is installed, you can launch it using a simple command. Run the following command to launch the Cypress Test Runner:

Using npx ensures you’re running the Cypress executable directly from your node_modules directory without needing to install it globally. This is the preferred method because it avoids global dependencies that could conflict with other projects. 

Upon running the command, the Cypress Test Runner will launch in a separate window. The Test Runner is a visual interface where you can manage, write, and execute your tests in real-time. Think of it as your command center for running tests and analyzing their results.

What Happens When You First Open Cypress?

Cypress will automatically create a default folder structure in your project, including the following directories:

• /integration/ : This is where your actual test files go.
• /fixtures/ : Here, you store static data used in your tests (like mock API responses).
• /support/ : Contains support files that are automatically included before each test (e.g., custom commands).
• /plugins/ : If you need custom plugins or want to extend Cypress’s functionality, this is the place for that.

This directory structure is crucial for organizing your tests, fixtures (mock data), and support files. It’s designed to keep your tests modular and easy to maintain.

Step 3: Running Your First Test

To help you get started, Cypress includes several example tests right out of the box.

1. Locate Example Tests : Navigate to the /cypress/integration/ folder, and you’ll find example test files already set up for you. These example tests are a great way to get familiar with Cypress’s API and the types of commands you’ll be using frequently.

2. Run a Test : Simply click on one of the example test files within the Cypress Test Runner, and watch as Cypress opens a browser and executes the test. You’ll see the test steps play out in the browser itself, with each step logged in real-time in the Test Runner’s command log.

4. Writing Test in Cypress

Every Cypress test follows a standard structure that includes two core components: describe blocks, which group related tests, and it blocks, which define individual test cases.

Let’s look at a clean and concise example:

What this code snippet means:

• describe() : This is used to group together multiple related test cases. It’s a simple way of logically organizing tests, particularly when you have multiple tests covering different features of your application.
• it() : This defines an individual test case. Inside each  it() block, you describe a specific action or behavior that you want to test. The first argument is the name of the test, and the second argument is a function containing the actual test steps.
• cy.visit() : This command opens the specified URL in a browser. Here, we’re using Cypress to visit the  https://example.com page. This is a core Cypress function that’s essential for any test that involves navigating to a web page.
• cy.title().should() : This is where the real test happens.  cy.title() grabs the title of the current page, and  .should() is used to make an assertion. In this case, we’re checking that the title of the page includes the text  "Example Domain" . Assertions like this verify that your app behaves as expected.

Of course, we recommend that you read through Cypress documentation to gain deeper understanding of Cypress syntax. 

5. Cypress Testing Best Practices

1. use test isolation & clean up state between tests.

• Why : Cypress maintains the browser’s state across tests by default, meaning that cookies, local storage, and sessions persist between test cases. This can cause one test's state to interfere with the next, leading to flaky tests.
• Best Practice : Each test should run independently to avoid side effects from prior tests. Use the beforeEach() hook to reset the application state or clear any persistent data. Consider resetting the database or test environment between tests if needed, especially for complex applications.

2. Use cy.intercept() for Network Stubbing

• Why : Cypress allows you to mock and stub HTTP requests, which speeds up tests by avoiding unnecessary reliance on actual network responses.
• Best Practice : Use cy.intercept() to stub API responses, making tests more stable and faster. You can mock successful responses or even simulate failure cases. You can test different scenarios like timeouts, 500 errors, and slow responses using cy.intercept() . This lets you handle various network conditions in a controlled way.

3. Leverage Custom Commands

• Why : Custom commands help reduce repetition and make tests more readable. They allow you to abstract complex actions into reusable functions.
• Best Practice : Define custom commands for commonly repeated tasks like login, form submissions, or navigating through your app. Group related custom commands in separate files under the support/commands.js directory for better organization, and ensure they’re well-documented.

4. Utilize Cypress' Built-In Retry-Ability

• Why : Cypress automatically retries commands if an assertion or action fails, ensuring that tests don’t fail unnecessarily due to temporary conditions like slow UI elements.
• Best Practice : Trust Cypress’s built-in retry mechanism instead of adding manual cy.wait() commands. Use assertions that leverage this retry ability. Minimize the use of cy.wait() , and if it’s necessary, use dynamic waits based on UI changes instead of hardcoded waits. For example, wait for a specific network call to finish using cy.intercept() instead of using cy.wait(5000) .

5. Run Tests in Parallel and Leverage CI Pipelines

• Why : Running tests sequentially can be slow, especially in large test suites. Cypress supports parallel test execution, which speeds up your CI/CD pipeline.
• Best Practice : Set up parallelization in your CI pipeline using Cypress's Dashboard Service or third-party CI tools. Configure your CI to distribute tests across multiple machines. Optimize test splitting in your CI pipeline to balance the load across parallel instances, and make sure to run high-priority or critical tests in a dedicated suite.

6. Avoid Hardcoding Selectors

• Why : Hardcoded selectors based on class names or IDs are prone to breaking if the UI changes. Cypress recommends using data attributes ( data-* ) for more stable and predictable selectors.
• Best Practice : Use data-* attributes in your HTML elements specifically for testing. You can create a consistent selector strategy across your project (e.g., all test-related selectors use the data-cy prefix). This makes tests more maintainable, and ensures that updates to the UI don’t accidentally break your tests. Let's say your HTML code for the button is <button data-cy="submit-button">Submit</button> . Your code can be:

6. Debugging in Cypress

Cypress takes the guesswork out of debugging by integrating seamlessly with Chrome DevTools. When a test fails, you don’t have to search through endless logs or re-run the test multiple times to figure out what went wrong. Instead, Cypress gives you real-time feedback, making it easy to pinpoint the exact issue. You can use:

• Time Travel : Cypress takes snapshots at each step of the test execution. You can hover over each command in the Command Log to see what your app looked like at that specific moment.
• Chrome DevTools Integration : Cypress allows you to directly interact with Chrome DevTools while tests are running. You can pause the test execution, inspect elements, view network requests, and step through the code.

Cypress also excels in how it handles test failures. When a test fails, Cypress doesn’t just leave you with a generic error message. It provides a full trace of the failure, including a detailed explanation of the error, a screenshot of the browser at the moment of failure, and even a video of the test execution if video recording is enabled.

• Screenshots on Failure : By default, Cypress captures a screenshot whenever a test fails. This screenshot is automatically saved, allowing you to visually inspect the state of the application at the time of failure. This feature is particularly useful when diagnosing issues in headless test runs, where you don’t have a browser window open.
• Video Recording : In addition to screenshots, Cypress can also record videos of your entire test suite execution. If a test fails, you can replay the video to see exactly what happened.

7. Cypress vs Selenium vs Playwright

Here's a quick comparison of Cypress vs other open-source frameworks for you:

8. Explore No-code and Low-code Options

Cypress is an amazing framework, no doubt. However, you know the struggle.  We’ve all been there—running a test suite that works perfectly one day, only to have it mysteriously fail the next. Flaky tests are those unreliable ones that randomly pass or fail, often due to timing issues, async calls, or dependencies on third-party services. They leave you scratching your head, wondering, “Did the code break, or is the test just acting up?”

Then comes the setup headaches. Cypress is among the easier ones to set up. Some testing frameworks require elaborate setup processes with intricate dependencies, browser drivers, and configurations, such as Selenium, just getting your environment up and running can feel like more of a coding project than your actual app development.

And then when tests fail, sometimes you’re left staring at cryptic error logs or digging through endless console messages. Figuring out what went wrong can take longer than writing the actual test.

The solution? No-code/low-code testing tools.

It's no buzzword. No-code/low-code testing tools simplify your testing life in so many ways.

1. Faster Test Creation

Traditional code-based testing can be slow, requiring developers to write test scripts for each scenario. On the other hand, Katalon Studio offers up to 3 testing modes for maximum flexibility:

• No-code: With the Record-and-Playback feature, testers can easily record their manual on-screen actions, which are then automatically converted into an executable test script. This allows testers to replay these recorded actions as often as they need, turning manual testing steps into automated tests without writing any code.
• Low-code: Katalon offers a library of Built-in Keywords , which are essentially pre-written code blocks with customizable parameters. These keywords are designed to perform specific actions, such as the “Click” keyword, which contains the internal logic needed to locate an element (like a button) and execute the click action. Testers only need to specify the element they want to interact with, without worrying about the underlying implementation details.
• Full-code: For more flexibility, testers can switch to Scripting Mode , allowing them to write test scripts manually if needed. The beauty of Katalon is that testers can toggle between no-code, low-code, and full-code options at any point. This multi-mode flexibility means that testers can enjoy the convenience of record-and-playback while also diving into the script when more complex logic is needed. Ultimately, this hybrid approach allows teams to focus on what to test rather than how to write the tests, boosting overall productivity.

2. Lower Technical Barrier

No-code/low-code tools empower non-technical team members like QA engineers, business analysts, or even stakeholders to participate in testing. These tools reduce dependency on the development team for creating or maintaining tests, making testing more collaborative.

3. Maintenance Made Easy As codebases evolve, traditional test scripts often break due to changing elements or workflows, leading to high test maintenance costs. No-code tools simplify this by offering self-healing tests , where the tool automatically adapts to minor changes in the application’s UI or logic.

4. Scalability Without Complexity

No-code tools make it easy to scale test coverage without the complexity of writing more code. You can rapidly create new tests by cloning or modifying existing workflows and scale testing across multiple environments with minimal effort. In Katalon, you can test across a wide range of browsers, devices, and operating systems within one place.

Download Katalon And Start Testing Today  

Thanks for reaching out!

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

• Trending Now
• Foundational Courses
• Data Science
• Practice Problem
• Machine Learning
• System Design
• DevOps Tutorial

Cypress – not() Method

The not() method in Cypress is used to exclude elements from a selection that match certain criteria or selectors. This method is particularly helpful when you want to interact with a group of elements but need to exclude specific ones that meet a condition. It provides a more refined control over element selection, allowing you to focus only on the elements you want.

In this article, we are going to learn, not() method of Cypress in detail.

Usage of Cypress – not() Method

The not() method in cypress allows you to remove elements from a selection based on a specified condition. This can be useful in complex UI structures where you want to work with multiple elements but exclude specific ones.

• selector : A detail to select the elements.
• excludeSelector : A CSS selector or condition to exclude specific elements from the selection.

Example 1: Excluding Elements from a List

Cypress Test Code

The test will visit the page and select all list items with the class item. The not(‘.exclude’) method will exclude the list items with the class exclude (i.e., Item 2 and Item 4). The test asserts that three elements remain after excluding the ones with the exclude class.

Explanation

• HTML Structure : The unordered list contains five list items, and two of them have the class exclude.
• Test Strategy : We first select all items using cy.get(‘.item’), then apply the not() method to exclude those with the class exclude. The test asserts that three list items remain after exclusion.

Example 2: Excluding Disabled Buttons

The test visits the page and selects all buttons with the class btn. The not(‘[disabled]’) method will exclude any buttons that have the disabled attribute (i.e., Button 2 and Button 4). The test asserts that two buttons remain after excluding the disabled ones.

• HTML Structure: The HTML contains four buttons, two of which are disabled using the disabled attribute.
• Test Strategy : The test selects all buttons using cy.get(‘.btn’) and applies not(‘[disabled]’) to exclude the disabled buttons. The test verifies that two enabled buttons remain.

The not() method is a versatile tool in Cypress that helps you exclude specific elements from a selection based on certain criteria. This method is highly useful in tests where you want to interact with most, but not all, elements matching a selector. By using not(), you can streamline your test logic and improve the clarity of your interactions with elements.

Can I use multiple selectors with the not() method?

Yes, you can combine selectors within the not() method to exclude multiple conditions or classes. For example, .not(‘.exclude, .disabled’) would exclude both exclude and disabled classes.

What happens if no elements match the exclusion condition?

If no elements match the exclusion criteria, the not() method will return the original selection unchanged.

Can I use not() with pseudo-classes?

Yes, you can use pseudo-classes like :first-child, :last-child, etc., within the not() method to exclude elements based on their structural position.

Please Login to comment...

Similar reads.

• Testing Tools
• Top 10 Fun ESL Games and Activities for Teaching Kids English Abroad in 2024
• Top Free Voice Changers for Multiplayer Games and Chat in 2024
• Best Monitors for MacBook Pro and MacBook Air in 2024
• 10 Best Laptop Brands in 2024
• 15 Most Important Aptitude Topics For Placements [2024]

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

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 can not load page #23344

minhui-foxtel commented Aug 15, 2022

nagash77 commented Aug 15, 2022

Sorry, something went wrong.

sosnowskijakub commented Aug 19, 2022 • edited Loading

Nagash77 commented aug 22, 2022.

No branches or pull requests

Handling Iframes in Cypress: Native Methods vs. cypress-iframe Plugin

Balaji Kumarasamy

August 30, 2024

Iframe Overview

1. cypress-iframe plugin, 2. native cypress methods, recommendation.

• -> Approach 1: Using .get(0) to Access the document
• -> Approach 2: Using .find(‘body’) to Access the Iframe Content
• ->We can create a custom function to access iframes elements:
• ->Approach3:  Negative test/ not recommended

In this article, we explore how to effectively handle iframes in Cypress, a powerful tool for end-to-end testing. Iframes present unique challenges in web testing due to their separate DOM context, but with the right strategies, you can efficiently interact with them. We’ll discuss best practices for iframe handling, and provide sample iframe application and respective scripts. 

An inline frame (iFrame) is an element that loads another HTML element inside of a web page . They are commonly used to embed specific content like external ads, videos, tags, or other interactive elements into the page.

Interaction with iframes can be challenging and may cause failures because iframes have a separate DOM context, traditional methods of interaction can fail, necessitating specialized approaches using cypres.

Here’s a breakdown of the two primary approaches:

The cypress-iframe plugin provides simplified commands to manage iframe interactions:

• Ease of Use : Commands like frameLoaded() and iframe() simplify iframe handling, making tests more readable and quicker to write.
• Efficiency : Reduces boilerplate code, allowing testers to focus on business logic rather than technical intricacies.
• Dependency Management : Adds a third-party dependency that requires monitoring for updates and compatibility.
• Limited Control : Abstracts details, which can complicate debugging and handling of edge cases.

Gleb Bahmutov , a prominent Cypress expert and a well-known figure in the Cypress testing community, strongly advocates for using native Cypress commands due to their seamless integration and the performance benefits they offer.

Advantages:

• No External Dependencies : Avoids relying on third-party plugins, reducing potential maintenance issues.
• Greater Control : Provides complete control over iframe interactions, using commands like cy.get().its(‘0.contentDocument.body’) to access iframe content.
• Custom Commands : Encourages creating reusable custom commands to handle iframes consistently across tests.

Example Custom Command:

• Use cypress-iframe if you prioritize simplicity and rapid test development, especially in projects with frequent iframe use and simpler testing needs.
• Adopt Native Methods if you require more control and stability, avoiding external dependencies, particularly in complex or long-term projects.

Best practices for testing iframes using native methods:

• Ensure you are using Cypress version 10 or later. Currently, we are using version 10.11.0
• Cypress does not automatically have access to the DOM inside iframes.

Test Application:

-> Approach- cy.iframe(): Not able to access the ‘.button’ class and leading to timeout error.

Test Report:

-> Approach 1: Using .get(0) to Access the document

This approach directly accesses the iframe’s document object, allowing you to manipulate it using Cypress methods:

.get(0): This method retrieves the document element from the jQuery object representing the iframe. It’s the equivalent of accessing iframe.contentDocument in plain JavaScript

-> Approach 2: Using .find(‘body’) to Access the Iframe Content

This method involves accessing the body of the iframe document and then using Cypress commands within that context:

.find(‘body’) : This method finds the body element within the iframe’s document. It’s a more specific way of scoping the query to the body, which is useful if you want to ensure that you’re interacting within the visible area of the iframe.

->We can create a custom function to access iframes elements:

The clickButtonInIframe custom command assumes it is defined in cypress/support/commands.js

->Test Script:

Test Reports:

->Approach3:  Negative test/ not recommended

Attempt to directly access the button inside iframes 1,2 without proper access.

Wrapping Up

Mastering the handling of iFrames in Cypress is essential for any developer or tester working with complex web applications. By following the best practices and sample scripts outlined, you can ensure reliable and efficient test interactions with iframe content, enhancing the quality of your testing efforts. We welcome your feedback on these suggested approaches.

Also Read this Detailed Guide on Cypress Testing Framework

Balaji Kumarasamy is a seasoned QA practitioner specializing in both front-end and back-end automation. He leads teams towards excellence in testing practices and is a proactive content creator and blogger in the QA space.

Related Blogs

Cypress Parallel Testing: A Step-by-Step Tutorial with Code Examples

Gunjan Kaushik

November 17, 2023

Cypress Assertions

Yogesh Solanki

August 29, 2023

Cypress Debugging: How to Get Started

Kailash Pathak

June 20, 2024

Cache and restore cookies , localStorage , and sessionStorage (i.e. session data) in order to recreate a consistent browser context between tests.

The cy.session() command will inherit the testIsolation value to determine whether or not the page is cleared when caching and restoring the browser context.

Correct Usage

Incorrect Usage

Arguments ​

id (String, Array, Object)

A unique identifier that will be used to cache and restore a given session. In simple cases, a String value is sufficient. In order to simplify generation of more complex ids, if you pass an Array or Object , Cypress will generate an id for you by deterministically stringifying the value you pass in. For example, if you pass ['Jane', '123', 'admin'] , an id of ["Jane","123","admin"] will be generated for you.

See the choosing the correct id to cache a session section for a more thorough explanation with examples.

Note that large or cyclical data structures may be slow or difficult to serialize into an identifier, so exercise care with the data you specify.

setup (Function)

This function is called whenever a session for the given id hasn't yet been cached, or if it's no longer valid (see the validate option). After setup and validate runs for the first time, Cypress will preserve all cookies, sessionStorage , and localStorage , so that subsequent calls to cy.session() with the same id will bypass setup and just restore and validate the cached session data.

The page is cleared before setup when testIsolation is enabled and is not cleared when testIsolation is disabled.

Cookies, local storage and session storage in all domains are always cleared before setup runs, regardless of the testIsolation configuration.

options (Object)

• cy.session() yields null .

Updating an existing login custom command ​

You can add session caching to your login custom command . Wrap the inside of the command with a call to cy.session() .

With session validation

Updating an existing login helper function ​

You can add session caching to a login helper function by wrapping the inside of the function with a call to cy.session() .

Switching sessions inside tests ​

Because cy.session() clears the page and all session data before running setup , you can use it to easily switch between sessions without first needing to log the previous user out. This allows tests to more accurately represent real-world scenarios and helps keep test run times short.

Validating the session ​

The validate function is used to ensure the session has been correctly established. This is especially helpful when a cached session is being restored, because if the session is not valid, cy.session() will recreate the session by re-running setup .

The following scenarios will mark the session as invalid:

• the validate function throws an exception
• the validate function returns a Promise that resolves to false or rejects
• the validate function contains failing Cypress command
• the last Cypress command in the validate function yielded false

Here are a few validate examples:

Modifying session data before caching ​

If you want to change which session data is cached, you can modify cookies, localStorage , sessionStorage as-necessary in setup .

Caching session data across specs ​

If you want to use the same session across multiple specs in the same Cypress run on the same machine, add cacheAcrossSpecs=true to the session options to leverage the session through the run.

Multiple login commands ​

A more complex app may require multiple login commands, which may require multiple uses of cy.session() . However, because the id value is used as a unique identifier to save and restore sessions, it's very important that it's actually unique per session.

In the following example, if the resulting session data that loginByForm and loginByApi create is different in any way , it would be a mistake to specify [name, password] as the id for both, because there would be no way to distinguish between the sessions created by loginByForm("user", "p4ssw0rd") and loginByApi("user", "p4ssw0rd") . Instead, you can modify the id to differentiate its value between both login functions, so that each will always be cached uniquely.

Where to call cy.visit() ​

Intuitively it seems that you should call cy.visit() immediately after cy.session() in your login function or custom command, so it behaves (from the point of view of the subsequent test) exactly the same as a login function without cy.session() .

However, if you want to test something on a different page, you will need to call cy.visit() at the beginning of that test, which means you will be calling cy.visit() a second time in your test. Since cy.visit() waits for the visited page to become active before continuing, this could add up to an unacceptable waste of time.

Tests will obviously be faster if you call cy.visit() only when necessary. This can be easily realised by organizing tests into suites and calling cy.visit() after logging in, inside a beforeEach hook.

Updating a login function that returns a value ​

If your custom login command returns a value that you use to assert in a test, wrapping it with cy.session() will break that test. However, it's usually easy to solve this by refactoring the login code to assert directly inside setup .

Cross-domain sessions ​

It's possible to switch domains while caching sessions, just be sure to explicitly visit the domain in your login command before calling cy.session() .

When the page and session data are cleared ​

Test isolation enabled ​.

The page is cleared and cookies, local storage and session storage (session data) in all domains are cleared automatically when cy.session() runs and test isolation is enabled with testIsolation=true (default in Cypress 12), This guarantees consistent behavior whether a session is being created or restored and allows you to switch sessions without first having to explicitly log out.

Note: cy.visit() must be explicitly called afterwards to ensure the page to test is loaded.

Test Isolation Disabled ​

When test isolation is disabled with testIsolation=false , the page will not clear, however, the session data will clear when cy.session() runs.

cy.visit() does not need to be called afterwards to ensure the page to test is loaded.

NOTE: Disabling test isolation may improve performance of end-to-end tests, however, previous tests could impact the browser state of the next test and cause inconsistency when using .only(). Be mindful to write isolated tests when test isolation is disabled.

When test isolation is disabled, it is encouraged to setup your session in a before hook or in the first test to ensure a clean setup.

Session caching ​

Once created, a session for a given id is cached for the duration of the spec file. You can't modify a stored session after it has been cached, but you can always create a new session with a different id .

In order to reduce development time, when running Cypress in "open" mode, sessions will be cached for spec file reruns .

To persist a session across multiple specs, use the option cacheAcrossSpecs=true .

Explicitly clearing sessions ​

When running Cypress in "open" mode, you can explicitly clear all spec and global sessions and re-run the spec file by clicking the "Clear All Sessions" button in the Instrument Panel .

For debugging purposes, all spec and global sessions can be cleared with the Cypress.session.clearAllSavedSessions() method.

Where to call cy.session() ​

While it is possible to call cy.session() explicitly inside a test or beforeEach , it is considered a best practice to call cy.session() inside a login custom command or reusable wrapper function. See the Updating an existing login custom command and Updating an existing login helper function examples for more details.

Choosing the correct id to cache a session ​

In order for sessions to be cached uniquely, the id argument must be unique for each new session created. The id provided to cy.session() will display in the reporter, thus we do not recommend using sensitive data like passwords or tokens as unique identifiers.

If you have custom login code that uses multiple parameters (in this example, a name, a token, and a password), in order to be able to log in many different users, but the id only included one of them (in this example, name ):

If you ran this, user1 would be logged in with token1 and p4ssw0rd , and a session would be created and cached using "user1" as the id .

Now let's say you wanted to try to log in the same user, but with a different token and/or password, and expect a different session to be created and cached. You run this, but because cy.session() is only being passed name as its id , it won't create a new session, but will instead load the saved session for "user1" .

In summary, you need to ensure that the id is unique. Create it from all the parameters used inside the setup function that may change, otherwise id values may collide and create unexpected results.

In this example, setting the id to [name, uniqueKey] guarantees that calling login() with different name , token and password values will create and cache unique sessions.

The uuid npm package can be used to generate random unique ids if an arbitrary name-space does not meet your needs.

Common Questions ​

Why are all my cypress commands failing after calling cy.session() ​.

When testIsolation is enabled, ensure that you're calling cy.visit() after calling cy.session() , otherwise your tests will be running on a blank page.

Why am I seeing 401 errors after calling cy.session() ? ​

It's possible that your session is not valid or was not fully established before the session was saved and the command ended. Be sure to specify a validate function so that cy.session() can validate and recreate the session if necessary.

Command Log ​

The instrument panel ​.

Whenever a session is created or restored inside a test, an extra instrument panel is displayed at the top of the test to give more information about the state of your sessions.

Clicking any session id in the panel will print that session's details to the console, and clicking the "Clear All Sessions" button will clear all saved spec and global sessions and re-run the spec file (see Session caching for more details).

The command log ​

Whenever cy.session() is called, the command log will show one of the following lines, which includes the status of the session call along with the session id value:

No saved session was found, so a new session was created and saved:

A saved session was found, and used:

A saved session was found, but the validate function failed, so the session was recreated and saved:

Note that in cases where the validate function fails immediately after setup creates the session, the test will fail with an error.

Expanding the session group in the command log will show all of the commands that were run when creating and/or validating the session.

In this image, a saved session is restored, but when /personal is visited in the validate function, the app redirects to /signin , which invalidates the session. A new session is created by visiting /signin where the user is logged in, after which, validation succeeds, and the session is available for the remainder of the test.

Printing to the console ​

Clicking a session id in the Instrument Panel or clicking the first line under an expanded session group in the command log will print that session's details to the console. This information contains the id along with any cached session data, including cookies, localStorage and sessionStorage .

• Authenticate faster in tests with the cy.session command
• Custom Commands
• Cypress.session
• Updating an existing login custom command
• Updating an existing login helper function
• Switching sessions inside tests
• Validating the session
• Modifying session data before caching
• Caching session data across specs
• Multiple login commands
• Where to call cy.visit()
• Updating a login function that returns a value
• Cross-domain sessions
• When the page and session data are cleared
• Test Isolation Enabled
• Test Isolation Disabled
• Session caching
• Explicitly clearing sessions
• Where to call cy.session()
• Choosing the correct id to cache a session
• Common Questions
• The Instrument Panel
• The command log
• Printing to the console