DEV Community: Kailash Pathak

How to Write Your First Cypress Test [With Examples]

Kailash Pathak — Thu, 20 Jun 2024 12:16:15 +0000

Choosing an ideal testing framework, especially with a different technology stack, can be challenging for new users, particularly those switching from other testing tools to Cypress. This shift might involve adapting to unfamiliar technological stacks. However, Cypress addresses this challenge by providing an in-built tool called ‘Cypress Studio’.

There are two ways to write your first Cypress test:

Using ‘Cypress Studio’
Writing your script

In this blog, we will discuss how a new user can start his journey in Cypress and efficiently write the first Cypress test. You will also see the implementation of Cypress tests on local machines and cloud grids.

What is Cypress Studio?

Cypress Studio provides a user-friendly interface for test case creation. It is a record and playback tool that captures user interactions with the application being tested. Using Cypress Studio, you can record user interactions in JavaScript. Whatever the step you follow in UI, Cypress Studio automatically records the steps in the backend in the test file

Here are some benefits of using Cypress Studio:

Record and Playback

The interface supports a record-and-playback mechanism, allowing users to record their interactions with the application. This feature is particularly useful for users who may not have extensive programming knowledge, enabling them to create test scripts without manually writing code.

Codeless Test Automation

One of the primary advantages of Cypress Studio is its codeless approach. Users can create and edit test scripts without writing code, making it accessible to individuals with limited programming knowledge. This lowers the entry barrier for manual testers and non-developers to participate in test automation.

Reduce Learning Curve

The simplicity and clarity of Cypress Studio’s interface reduce the learning curve for users new to automated testing. This enables teams to onboard new members quickly and encourages broader team participation in the testing process.

Fast Script Creation

Cypress Studio records all the steps of UI interaction so if someone wants to create the script fast he/she can record the script and can re-use the record script for further development.

Debugging the script

Debugging in Cypress Studio involves examining and modifying the recorded script to ensure it accurately reflects the intended test scenario. Users can edit and debug the recorded script. This flexibility allows users to tweak tests as needed, which strikes a balance between codeless development and human scripting.

In the next section, you will see how we can set up Cypress Studio.

**Test website on different browsers like Chrome, Safari, Firefox, and Opera for free on LambdaTest platform. Easily test on 3000+ desktop & mobile environments.**

Setting up Cypress Studio

Before setting up Cypress Studio, you need to install Cypress. You can install Cypress using the following commands:

npm install cypress --save-dev

yarn add cypress --dev

In the screenshot below, you can see that the latest version of Cypress has been installed. However, when writing this blog on your first Cypress test, Cypress’s latest version was 13.6.2.

The next step is to enable Cypress Studio. To enable this feature, we must set experimentalStudio:true in the configuration file.

 const { defineConfig } = require("cypress");
module.exports = defineConfig({
 e2e: {
   experimentalStudio:true,
   setupNodeEvents(on, config) {
     // implement node event listeners here
   },
 },
});

We have updated the cypress.config.js (configuration file)to enable the Cypress Studio feature. Now, the next step is to record the script.

Ways of Recording the Script

We can record the script using Cypress Studio. Below are two options to record the script:

Create a test with Cypress Studio
Add New Test

Using the ‘Create test with Cypress Studio’ Option

You should have some existing test cases before recording using the option ‘Create test with Cypress Studio’ in Cypress Runner.

Let’s run the following command to open Cypress Runner.

yarn cypress open

After opening the Cypress Runner, run an existing test case. As we run the command, it will open Cypress Runner with the option ‘Create test with Cypress Studio.’

Clicking on the ‘Create test with Cypress Studio’ link in the Cypress Test Runner initiates Cypress Studio and prompts you to provide the URL of the application you want to test.

Let’s record the test scenario below.

Open the site https://ecommerce-playground.lambdatest.io/.
Click on My Account.
Enter User Name.
Enter Password.
After logging in, log out of the application.

Once we record the above scenario, we will be asked to save the recorded commands.

Let’s save the command that is recorded by providing the recorded script’s name.

Once we save the recorded script, it is automatically saved under the path ‘e2e/LTCypressStudio’. This path indicates the location within your Cypress project where the test script file is stored.

Below is the recorded script where you can see the generated code. Once the recording is done, it will end with line /*==== End Cypress Studio ==== */

describe('Cypress Studio Recorded Script', () => {
/* ==== Test Created with Cypress Studio ==== */
it('LTCypressStudio', function() {
 /* ==== Generated with Cypress Studio ==== */
 cy.visit('https://ecommerce-playground.lambdatest.io/');
 cy.get('#widget-navbar-217834 > .navbar-nav > :nth-child(6) > .nav-link > .info > .title').click();
 cy.get('#input-email').clear('lambdatestnew@yopmail.com');
 cy.get('#input-email').type('lambdatestnew@yopmail.com');
 cy.get('#input-password').clear();
 cy.get('#input-password').type('Password1');
 cy.get('form > .btn').click();
 /* ==== End Cypress Studio ==== */
})
})

We have seen above one option to record the script by clicking on the link ‘Create test with Cypress Studio’ from Cypress Runner.

Let’s see the second option, i.e., ‘Add New Test’ to record the script.

Dive into the world of XPath Tester to streamline your web scraping and automation projects. Discover its features, uses, and best practices for optimal performance.

Adding New Test

This option is used when you want to create a completely new Cypress test. It lets you define and execute specific test scenarios in a new file.

As we click on ‘Add New Test,’ it will ask us to enter the URL. Let’s record the scenario below.

Open the site https://www.lambdatest.com/selenium-playground/auto-healing.
Enter User Name.
Enter Password.
Click on the Submit button.

After recording, click Save Commands. Let’s give the name ‘LambdaTestAddNewTest.’

Once we save the script by giving some name, the test case executes and passes successfully. Below is the recorded script by Cypress Studio.

 /* ==== Test Created with Cypress Studio ==== */
 it('https://www.lambdatest.com/selenium-playground/auto-healing', function() {
   /* ==== Generated with Cypress Studio ==== */
   cy.visit('https://www.lambdatest.com/selenium-playground/auto-healing');
   cy.get('#username').clear();
   cy.get('#username').type('LambdaTest');
   cy.get('#password').clear();
   cy.get('#password').type('Test@1234');
   cy.get('form > .flex > .bg-black').click();
   /* ==== End Cypress Studio ==== */
 });

Modifying the Existing Script

Using Cypress Studio, we can add new scripts and update the existing script with more commands.

Add Commands to Test

This option is useful when adding Cypress commands to an existing test. It allows you to extend the functionality of an already defined test or modify its behavior by incorporating additional Cypress commands.

Let’s update one of the previously recorded scripts where we are login into https://ecommerce-playground.lambdatest.io/

it('LTCypressStudio', function() {
   /* ==== Generated with Cypress Studio ==== */
   cy.visit('https://ecommerce-playground.lambdatest.io/');
   cy.get('#widget-navbar-217834 > .navbar-nav > :nth-child(6) > .nav-link > .info > .title').click();
   cy.get('#input-email').clear('lambdatestnew@yopmail.com');
   cy.get('#input-email').type('lambdatestnew@yopmail.com');
   cy.get('#input-password').clear();
   cy.get('#input-password').type('Lambda123');
   /* ==== End Cypress Studio ==== */
 })

Cover the below scenario to update the existing script using Cypress Studio.

After logging in, search for the text ‘HP.’
Click on the first item in the search results.
Click on Add to Cart.
Click on View Cart.

Click on ‘Add Commands to Test’ from Cypress Runner.

As part of Cypress Studio, when we click ‘Add Commands to Test,’ the complete test case is rerun. In our case, the user is logged in to the site. After that, we can search for the product ‘HP,’ add it to the cart, and redirect to the View Cart page.

The Cypress command log shows that each updated step is recorded with the ‘Save Commands’ button. Once you click the ‘Save Commands’ button, the script is updated with more steps.

The screenshot below shows that once the scenario is completed, the script will be updated with some more steps. You can see some more steps are added, so you can update the existing script using Cypress Studio. Below is the script that is recorded.

Cypress Studio is beneficial for those seeking to swiftly generate test scripts without needing to code, making it especially advantageous for novices getting started with Cypress.

Despite being a handy tool for rapidly creating code-free test scripts, Cypress Studio encounters difficulties when handling intricate test scenarios or scenarios incorporating dynamic data.

So far, we have seen how you can record scripts using the built-in tool Cypress Studio. In the next section, you will see how we can create a Cypress test case by writing our script.

Discover and evaluate JSONPath expressions with ease using the JSONPath tester tool. Perfect for quick debugging and testing. Try for free now!

Writing First Cypress Test Script

Writing Cypress scripts manually refers to crafting test code directly using JavaScript or TypeScript rather than relying on visual recording tools like Cypress Studio. Cypress uses Mocha as its default automation testing framework.

When you install Cypress, it automatically includes Mocha, and you don’t need to install Mocha separately to use it with Cypress. Integrating Mocha with Cypress provides a structured and organized way to write end-to-end tests. Cypress leverages Mocha’s syntax, which includes describe and it blocks for test organization, as well as hooks for setup and teardown, to create a clear and readable testing structure.

Before writing the script, we need to set up Cypress. Below are some of the steps that we have to follow.

Step 1: Install Cypress

To write the script on your own, let’s set up Cypress using the following commands:

npm install cypress —-save-dev

yarn add cypress —-dev

The screenshot below shows that Cypress’s latest version was 13.6.2 when this blog on writing your first Cypress test was written.

After installation, the folder structure looks like the one below, with different folders given in brief detail below.

The table below summarizes the purpose of each directory and file within the Cypress project.

Step 2: Create a Test File

Create a new test file under cypress/e2e/ to run the e2e test case. Let’s give a name to the file, e.g., lambdatest_test_spec.cy.js

Step 3: Write Your Test

As we mentioned above, Cypress supports the Mocha framework. Therefore, we must grasp key concepts before proceeding to our initial script.

describe() Block

Mocha uses the describe and it blocks to structure test suites and individual test cases.describe() is used to group tests.

it() Block

it() is used to define individual test cases.

Hooks

Mocha supports hooks such as before(), beforeEach(), after(), and afterEach(). Cypress utilizes these hooks for setup and teardown tasks, like preparing the test environment and cleaning up before running tests.

Assertions

Mocha itself doesn’t include built-in assertion libraries. Cypress, however, provides its assertion library and extends Mocha with Chai assertions. Cypress uses Chai assertions to assert conditions in your tests.

Some of the Examples are .should(‘have.text’, ‘Expected Text’),.should(‘not.equal’, ‘Expected Text’),.should(‘exist’),.should(‘not.be.disabled’), .should(‘have.class’, ‘active’), etc.

Excluding the Tests

You can use the .skip() method to exclude a specific Cypress test. This method can be applied to a Cypress test or a description block.

Excluding the Tests

You can use the .skip() method to exclude a specific Cypress test. This method can be applied to a Cypress test or a *description *block.

The describe.skip() function in Cypress is used to skip the entire test suite within the *describe *block. Here’s an example:

Including the Tests

You can use the .only() *method to run only specific tests or test suites during the test execution. When you use *.only *on a Cypress test or a suite, only that test or suite will be executed, and all other tests without *.only will be skipped.

So far, we have discussed some concepts required of a user writing his script for the first time. Let’s now put that knowledge into practice by crafting a simple Cypress Script.

Let’s write the script for the below scenario.

Open the URL https://ecommerce-playground.lambdatest.io/index.php?route=account/login.
Enter Email.
Enter Password.
Click on the Login button.
Search product ‘VAIO.’
Click the first product from the search result.
Verify that the searched product name should contain the text ‘Sony VAIO.’

Open lambdatest_test_spec.cy.js and write a simple Cypress test to visit a website, log in, and search for the product.

/// <reference types="cypress" />
describe("Lambdatest Login ",() => {
 it("Open the URL", () => {
   cy.visit(
     "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
   );
 });
 it("Login into the application", () => {
   cy.get('[id="input-email"]').type("lambdatest@yopmail.com");
   cy.get('[id="input-password"]').type("lambdatest");
   cy.get('[type="submit"]').eq(0).click();
 });
 it("Search the Product", () => {
   cy.get('[name="search"]').eq(0).type("VAIO");
   cy.get('[type="submit"]').eq(0).click();
 });
 it("Verify Product after search ", () => {
   cy.contains("Sony VAIO");
 });
});

Accessibility DevTools Chrome Extension redefines the standards of web accessibility testing chrome, your go-to Chrome extension on for developers, testers, and designers.

Code Walkthrough

Let’s do a code walkthrough to understand the script in detail.

describe Block

describe(“LambdaTest Login”, () => { … }): This block represents a test suite named ‘Lambdatest Login’ that contains multiple Cypress test cases related to the LambdaTest login functionality*.*

Open the URL

Visit the specified URL, which is the login page of the LambdaTest application.

Login into the application

Enter the Email and Password input fields, enter the respective values, and click the Login button.

In the script, we used different locator strategies to interact with elements on the web page. Locators identify and target HTML elements, allowing Cypress to perform actions like typing text, clicking buttons, etc.

Here is the detail of each locator used here:

[id=”input-email”]: Targets the input element with the ID attribute set to “input-email.”

[id=”input-password”]: This function targets the input element with the ID attribute set to “input-password.”

[type=”submit”]: This function targets the Submit button(s). The .eq(0) selects the first matching button.

Search the Product

You can search the data by entering a value in the input field, ‘VAIO,’ and clicking the Search button.

**[name=”search”]: **This function targets the input element with the *name *attribute set to “search.”

**[type=”submit”]: *This function targets the Submit button(s). The *.eq(0) selects the first matching button.

Verify Product after search

Verifies that the search results page contains the text “Sony VAIO.”

Discover best Android emulators Mac, comparing key features to find the perfect fit for your mobile app testing needs.

Step 4: Execute the Test Case

There are different ways of executing the Cypress test cases.

Headed mode: where we can see all executing steps in the browser window.
Headless mode: where we execute tests without loading a complete web browser.

Running Test in Headed Mode

To execute the Cypress test case in the headed mode locally, we must run the following command:

yarn cypress open

npx cypress open

As we run the command, it will open the below screen.

There are two options: E2E testing and Component Testing.

E2E Testing: E2E testing allows users to simulate user interactions, navigate through the application, and validate the application’s behavior as a whole.

Component Testing: Component testing focuses on testing individual application components in isolation. Component testing aims to verify that each application part behaves as expected independently of the other components.

Select E2E Testing from the above screenshot, then select the desired browser for testing. Finally, launch the Cypress Runner to initiate the testing environment.

Click on ‘lambdatest_test_spec.cy.js’ to start executing the tests, and finally, you will see all test steps passed.

Dive into automation testing using Selenium Java with this detailed tutorial. Master the essentials to begin your Selenium Java testing journey confidently.

Running Test in Headless Mode

By default, Cypress runs in ‘headless mode,’ where the browser runs in the background without opening a visible browser window.

The command to run the Cypress test case in headless mode is:

yarn cypress run

npx cypress run

The screenshot below shows that all test cases are executed successfully in a headless browser.

There are some other commands that you can use to execute the test cases.

Run a full test present in the e2e folder in the Headless mode:

Use the command:

npx cypress run

yarn cypress run

Run a particular test case on the default browser in the Headless browser:

The default browser is Electron when you run test cases in headless mode. Use the following command to execute a particular test case on the default browser:

npx cypress run --spec "cypress/e2e/lambdatest/lambdatest_test_spec.cy.js"

Selenium WebDriver: Automate browser activities locally or remotely. Explore Selenium components, version 4, and its pivotal role in automated testing

Execute test case on a particular browser in the Headless mode:

Use the following command to execute a specific test case on a particular browser. In this case, we are running on the Chrome browser in headless mode.

npx cypress run --browser chrome --spec "cypress/e2e/lambdatest/lambdatest_test_spec.cy.js"

So far, we have explored creating a test script using Cypress Studio and saw how to write the script manually. We have also reviewed different approaches for running these test cases in a local environment. Now, let’s see how we can execute the test cases in the cloud.

Running Cypress test cases in the cloud has various benefits. Cloud-based testing platforms provide scalability, allowing you to scale your testing infrastructure based on the project’s needs. They also enable parallel testing, allowing you to run multiple tests concurrently.

There are various cloud-based platforms in the market. LambdaTest emerges as a standout choice. LambdaTest is an AI-powered test orchestration and execution platform that lets you perform manual and automation testing at scale with over 3000+ browsers and OS combinations to help you automate Cypress test cases on the cloud. It also offers access to real devices and browsers, providing a more accurate simulation of how end-users will experience your web application.

How to Automate Your First Cypress Test on Cloud?

Running Cypress test cases on the cloud is crucial for comprehensive and accurate testing of modern web applications. As cloud testing environments like LambdaTest gain prominence, it becomes imperative to validate that the infrastructure supports the intricacies of testing. This ensures that Cypress test cases can be tested in cloud-based environments, guaranteeing the application’s reliability and functionality in real-world scenarios.

You can accelerate Cypress testing and reduce test execution time by multiple folds by running parallel tests on LambdaTest across multiple browsers and OS configurations.

Subscribe to the LambdaTest YouTube Channel for the latest updates on tutorials around Selenium testing, Cypress e2e testing, and more.

As we execute the test cases on the LambdaTest platform, we must configure our tests for the LambdaTest Cypress cloud grid.

Prerequisite:

You already have an account on LambdaTest .
You have an access token to run test cases on LambdaTest.

The Username and Access key can be obtained from the LambdaTest Dashboard.

Learn WebdriverIO for web automation and empower yourself with in-depth knowledge for smooth execution.

Configuring Cypress Test on LambdaTest

Step 1: Install the CLI

The command-line interface of LambdaTest enables us to execute your Cypress tests on LambdaTest. Use the Cypress CLI command via npm, as shown below.

npm install -g lambdatest-cypress-cli

Step 2: Generate lambdatest-config.json

Under the root folder, configure the browsers you want to run the tests. Use the *init *command to generate a sample lambdatest-config.json file or create one from scratch. Use the below command.

lambdatest-cypress init

In the generated lambdatest-config.json file, pass the information below. Fill in the required values in the lambdatest_auth, browsers, and run_settings* ***sections to run your tests.

In the file below, we pass three browsers (Chrome, Firefox, and Electron) and run the test case in two browsers simultaneously.

{
  "lambdatest_auth": {
     "username": "username",
     "access_key": "access_key"
  },
  "browsers": [
     {
        "browser": "Chrome",
        "platform": "Windows 11",
        "versions": [
           "latest-1"
        ]
     },
     {
        "browser": "Electron",
        "platform": "Windows 11",
        "versions": [
           "latest"
        ]
     },
     {
        "browser": "Firefox",
        "platform": "Windows 11",
        "versions": [
           "latest-1"
        ]
     }
  ],
  "run_settings": {
     "build_name": "Write First Script In Cypress",
     "parallels": 3,
     "specs": "./cypress/e2e/lambdatest/*.cy.js",
     "ignore_files": "",
     "network": true,
     "headless": false,
     "npm_dependencies": {
        "cypress": "13.6.2"
     }
  },
  "tunnel_settings": {
     "tunnel": false,
     "tunnel_name": null
  }
}

Run the below command to execute the test case on the LambdaTest.

lambdatest-cypress run --sync=true

As we run the above command, test execution starts, and test cases are run in parallel on the LambdaTest platform.

Learn to download and setup Selenium ChromeDriver to effortlessly run Selenium tests on Chrome browser.

Test Case Execution

As we execute the test cases in the screenshot below, both test cases start executing in browsers (Chrome, Firefox) parallelly, and we can see the detailed report in the LambdaTest dashboard.

LambdaTest Web Automation Dashboard offers users a convenient and intuitive interface to oversee test results, review test outcomes, and utilize various platform features. It enables live interactive testing, offering users a real-time view of the website or web application they are testing on a specific browser and operating system.

The screenshot below shows the test case starting to execute in browsers (Chrome, Firefox, and Electron).

The screenshot below shows that test cases are passed in the browser (Chrome, Firefox, and Electron).

Here is the console log of executed test cases in the Chrome browser. You can see that three of the test cases have passed on the LambdaTest Grid.

Here is the console log of executed test cases in the Firefox browser. You can see that three test cases have passed on the LambdaTest Grid.

Here is the console log of executed test cases in the Electron browser. You can see that three of the test cases have passed on the LambdaTest Grid.

If you’re a developer or tester looking to elevate your skills with Cypress, consider diving into the Cypress 101 certification to stay ahead of the game.

Explore the JUnit testing framework along with its architecture, JUnit 5 enhancement features and their differences, and more.

Conclusion

You have taken a comprehensive journey into Cypress test automation, breaking down the process step by step with live examples. You have also seen how to write the test case using the Cypress built-in tool ‘Cypress Studio’ and the manual script-writing process. Furthermore, you’ve explored the steps a new user can take to commence their Cypress experience and outlined effective strategies for starting to write scripts. Also, different ways of recording the script and how to update the existing script.

Furthermore, we’ve discussed the integration of LambdaTest, an AI-powered test orchestration and execution platform, and how it enhances the capabilities of Cypress automation. By seamlessly running our Cypress tests across different browser versions and platforms, you can ensure our applications’ compatibility and reliability in diverse environments. This integration empowers you to deliver high-quality web experiences to users across the digital landscape.

In this tutorial, learn how to Andriod automation apps using Appium framework.

Frequently Asked Questions (FAQs)

What is Cypress testing for?

Cypress testing is primarily used to automate the testing of web applications. It allows developers and QA engineers to write, run, and debug tests directly within the browser. Cypress provides a comprehensive testing framework that facilitates end-to-end testing, integration testing, and unit testing of web applications. It enables testers to simulate user interactions, such as clicking buttons, filling out forms, navigating through the application, and then asserting expected behaviors and outcomes. Overall, Cypress testing helps ensure web application functionality, performance, and reliability across various browsers and environments.

What are Cypress function tests?

Cypress function tests, also known as functional tests, are automated tests used to verify the functionality of web applications. In Cypress, function tests involve writing test scripts to simulate user interactions with the application’s features and functionalities. These tests validate whether the application behaves correctly according to its specifications and requirements.

Explore our comprehensive guide on Selenium testing. Learn what is Selenium, its architecture, benefits, and how to automate web browsers with this open-source suite.

How to Handle Shadow DOM in Cypress

Kailash Pathak — Thu, 07 Dec 2023 20:07:04 +0000

The concept of componentization has revolutionized website development, completely transforming how they are built. At the heart of this revolutionary shift is the introduction of Shadow DOM, a key component in this paradigm change. With Shadow DOM’s powerful method, developers can isolate styles, scripts, and markup within specific components. This encapsulation is a barrier, effectively shielding these components from the broader scope and avoiding accidental interference. The introduction of Shadow DOM marks a significant advancement in web development practices.

Developers may design modular and isolated components using Shadow DOM, guaranteeing their independence from the global scope. In addition to improving security, this separation makes maintenance easier and enables developers to concentrate on specific components without worrying about other variables interfering with their operation.

When it comes to automating elements within the Shadow DOM, it can be quite challenging compared to elements in the regular DOM. However, Cypress provides a solution for automating elements under the Shadow DOM.

In this blog, we will explore the complication of automating Shadow DOM in Cypress, a powerful end-to-end testing framework.

Don’t waste time decoding binary data manually. Try our Binary to Text Converter tool to convert binary data to text. No more tedious manual conversion needed!

What is a Document Object Model (DOM)?

The Document Object Model (DOM) is fundamentally a programming interface that web developers are given access to by browsers. It displays the document’s structure as a tree of objects, each representing a different aspect of the document, such as its components, attributes, and textual content. When it comes to web pages, developers can dynamically interact with them, altering their appearance and functionality in real-time. This is made possible by the hierarchical structure of web pages.

DOM serves as a fundamental interface for programs to dynamically manipulate the structure, style, and content of documents on the web. It empowers developers to create, read, update, and delete elements and attributes within a web page, enabling interactivity and dynamism. This dynamic capability of the DOM is crucial for crafting interactive web applications. By harnessing programming languages such as JavaScript, developers can access and modify the DOM, allowing them to build responsive and interactive web applications with unparalleled flexibility and power.

Document: The web page you see in your browser is a document. When a web page is loaded, the browser creates a DOM of the page.
Object: In the context of the DOM, an “Object” represents every element and component of a web page. These objects include paragraphs, headings, images, buttons, forms, etc. Each of these objects can be manipulated using code.
Model: The DOM represents the document so that programs can change its structure, style, and content while in the browser. It provides a way for programs to manipulate the structure, style, and content of web documents.

In the DOM, every branch within the tree structure leads to a node, which is a fundamental unit. These nodes are pivotal elements in the DOM, encapsulating various objects and data.

Each node represents a distinct document part, such as elements, attributes, and text content. This hierarchical arrangement allows web browsers to interpret and manipulate pages, enabling dynamic content and interactive user experiences.

Let us take an example of an HTML page. In this example, the HTML document contains a head section with a title element, setting the page title to “A simple web page”. The body section contains a heading element (< h1 *>) with the text “Hello LambdaTest” and a paragraph element (< *p >) with the text “How are you LambdaTest”. This HTML code would display a webpage with the specified content when rendered in a web browser.

<html lang=“en”>
   <head>
      <title>A simple web page</title>
   </head>
   <body>
      <h1>Hello LambdaTest</h1>
      <p>How are you LambdaTest</p>
   </body>
</html>

As mentioned above, a logical tree of this HTML structure would look like this.

Need to convert CSV to JSON? Try our free CSV to JSON converter tool to convert your CSV files to JSON format. Simple and easy to use. Try it now for free!

What is a Shadow DOM?

Shadow DOM stands for Shadow Document Object Model. It’s a web standard that offers a scoped subtree within a document, meaning that the DOM elements inside a Shadow DOM are hidden from the main document (& vice-versa). This encapsulation helps developers create widgets (or other components) with encapsulated styles and behaviors without worrying about conflicts with the styles or scripts of the main document (or other components).

It is particularly useful in web development when developers have to create isolated components with their styles and behavior, preventing conflicts with the styles and scripts of the main document or other components on the same page.

Shadow DOM enables the creation of multiple shadow trees alongside the standard document tree, representing the DOM structure of the entire project. Each tree possesses a root node, known as the shadow root, housing its unique elements and styling. These trees are linked to specific elements within the parent document tree or other shadow trees, with these connecting nodes referred to as shadow hosts. The demarcation line separating the regular DOM and the Shadow DOM is termed the shadow boundary.

Convert your JSON files to CSV format in seconds with our easy-to-use JSON to CSV Converter. It’s fast, reliable, and user-friendly, making data conversion simple.

Here are some of the key components of Shadow DOM:

Shadow Host

The regular DOM element to which a Shadow DOM is attached is the Shadow Host. It’s the element where the Shadow DOM is attached, effectively encapsulating the elements inside it.

Shadow Tree

Inside the Shadow DOM, there is a Shadow Tree. This tree comprises the encapsulated DOM elements and their associated styles and behavior.

Shadow Root

The shadow root is the root node of the shadow tree. It is a gateway between the Shadow DOM and the main document’s DOM.

Shadow Boundary

At this point, we transition from the Shadow DOM to the familiar territory of the regular DOM. Elements inside the Shadow DOM can’t be accessed or styled from outside the Shadow DOM unless specific mechanisms are provided.

Benefits of Shadow DOM

Shadow DOM offers several benefits in web development. Here are some key benefits:

Encapsulation

Protects DOM and styles from outside styles and scripts, preventing conflict. It also prevents styles and scripts from the outer document from leaking into the components, causing unintended styles and behavior.

Isolation

Gives styles and scripts limited scope, avoiding clashes with global styles and scripts, as globally applied CSS and JavaScript may cause name conflicts and unwanted side effects.

Reusability

Enables the creation of self-contained, reusable components that can be safely inserted into other web application components without worrying about style inconsistencies.

Simplified Styling

Makes style easier by letting you create CSS for a single component without worrying about how it will affect the rest of the document, as traditional styling might require complex selectors to avoid conflicts.

From SQL to JSON in a snap! Convert SQL queries to JSON effortlessly with our SQL to JSON converter, enhancing compatibility and data interchange. Try it now!

Let’s explore an example that demonstrates the process of attaching Shadow DOM to HTML and how it helps encapsulate the structure and styles of HTML.

Consider a simple example where you want to create a custom button component encapsulated within Shadow DOM:

In this example, we define a custom button component (< my-button >) that encapsulates its HTML structure and styles using Shadow DOM. The button’s appearance and behavior are isolated from the rest of the page, making it a self-contained component that can be used without interfering with the global CSS or JavaScript.

<!DOCTYPE html>
<html>
<head>
<title>Shadow DOM Example</title>
</head>
<body>
<my-button></my-button>
</body>
</html>


<script>
// Create a new custom element using the CustomElements API
class MyButton extends HTMLElement {
constructor() {
super();


// Create a Shadow DOM
const shadow = this.attachShadow({ mode: 'open' });


// Create a button element inside the Shadow DOM
const button = document.createElement('button');
button.textContent = 'Hi 👋 Click On Me';


// Add some styles to the Shadow DOM
const style = document.createElement('style');
style.textContent = `
button {
background-color: blue;
color: white;
padding: 10px 20px;
border: none;
cursor: pointer;
}
`;


// Attach the button and style to the Shadow DOM
shadow.appendChild(style);
shadow.appendChild(button);
}
}


// Define the custom element
customElements.define('my-button', MyButton);
</script>

Here’s a breakdown of the code:

The HTML document defines a < my-button > custom element inside the .
In the < script > block, a new custom element, *MyButton *is created by extending the *HTMLElement *class. The constructor of *MyButton *sets up the Shadow DOM and creates a button element inside it.
Inside the Shadow DOM, a button element is created and styled with a blue background, white text, padding, no border, and a pointer cursor.
The custom element is defined using customElements.define (‘ my-button ‘, MyButton);, associating the custom element tag name < my-button > with the MyButton class.

Get faster loading times and better user experience with our efficient JSON Stringify tool. Quickly compress your JSON data with ease and optimize your website now.

Output:

The ‘Hi 👋 Click On Me’ button is inside the Shadow DOM.

Before delving into how to handle Shadow DOM elements using Cypress, it’s crucial to understand how to access these elements. The upcoming explanation will illuminate these challenges and solutions for effective Shadow DOM element handling in Cypress.

How to Access Shadow DOM Elements?

Before discussing how we can handle Shadow DOM in Cypress, we must discuss what will happen if a user tries to access Shadow DOM elements without using the method that is provided by Cypress to handle these elements.

Let’s examine the consequences of attempting to directly access Shadow DOM in Cypress, with detailed examples below.

Use Case 1

Let’s take an example of the LambdaTest Playground, where we have to enter data in the Name and Email field.

Open the site https://www.lambdatest.com/selenium-playground/shadow-dom.
Enter data in the Name field.
Enter data in the Email field.

Let’s inspect the fields Name and Email. The screenshot below shows the Name and Email fields inside the shadow DOM.

Use our free online Random Number Generator tool to create unique non-repeating random numbers. Input your lower and upper range and get numbers with a click.

Let’s write Cypress code to enter data in the Name and Email text field and execute the code locally.

it('Enter data in Field Name and Email', () => {
cy.visit('https://www.lambdatest.com/selenium-playground/shadow-dom')
cy.get('[type="text"]').find('input[placeholder="Name"]').type('LambdaTest')
cy.get('[type="text"]').find('input[placeholder="Email"]').type('LambdaTest@qa.com'})
})

Upon running the code, the error "Expected to find element: #input, but never found it. Queried from:" appears in the command log below. The error occurs because the fields are within Shadow DOM.

Use Case 2

Let’s take another example of the LambdaTest Playground, where we enter data in Sign Up Form fields inside the shadow DOM.

Open the site https://www.lambdatest.com/selenium-playground/shadow-dom.
Enter data in the Username Field.
Enter data in the Email Field.
Enter data in the Password Field.
Enter data in the Confirm Password Field.

Let’s inspect the field. In the screenshot below, you can see that the Username and other fields are inside the shadow DOM

Let’s write Cypress code to enter data in the Username, Email, Password, and Confirm Password text fields.

it("Enter data in Fields Which are Inside the Shadow DOM ", () => {
cy.visit("https://www.lambdatest.com/selenium-playground/shadow-dom");
cy.get('[name="username"]').type("LambdaTest", { force: true });
cy.get('[name="email"]').type("LambdaTest@qa.com", { force: true });
cy.get('[name="password"]').type("LambdaTest123", { force: true });
cy.get('[name="confirm_password"]').type("LambdaTest123", { force: true });
});

Let’s run the above code. The screenshot below shows that the error displays Timed out retrying after 4000ms: Expected to find element: [name=”username”], but never found it. The reason is that fields are inside the Shadow DOM.

Before explaining how we can solve the above issue, it’s mandatory to understand the method we can use to access Shadow DOM elements.

Need to encode your text into UTF-8 format? Use our UTF-8 Encode tool to encode your text for seamless communication across all platforms and devices. Try it for free today.

Methods for Handling Shadow DOM

Below is the syntax to access the Shadow element. Let’s see the methods that are used in accessing the element that is inside the Shadow DOM with detail example

Syntax:

.shadow(selector)
.shadow(selector, options)

Example:

Cypress provides a way to traverse into the Shadow DOM of an element for testing purposes. To interact with elements inside the Shadow DOM in Cypress, you can use the .*shadow() *command.

Assuming you have an element with an ID of ‘my-element’ inside a Shadow DOM:

<my-element>
#shadow-root (open)
<div class="content">Hi LambdaTest Content inside shadow DOM</div>
</my-element>

To traverse into the Shadow DOM and interact with the element with class content, you can use the .shadow() command in your Cypress test.

In this example, cy.get(‘my-element’).shadow() is used to traverse into the Shadow DOM of the my-element and find the element with class content inside the Shadow DOM in Cypress.

// Your Cypress test
it('should interact with an element inside shadow DOM', () => {
// Visit your webpage
cy.visit('http://your-app-url');


// Find the host element with ID "my-element"
cy.get('my-element').shadow().find('.content').should('have.text', 'Hi LambdaTest Content inside shadow DOM');


// Perform interactions or assertions on the element inside the shadow DOM
// For example, click the element inside the shadow DOM
cy.get('my-element').shadow().find('.content').click();
});

In the next section, you will see how we can handle the elements inside Shadow DOM in Cypress using the above-mentioned methods.

Convert your URLs into a secure and easy-to-read format with our URL Encode tool. Make sharing links easier and secured. Simply input your URL and let us do the rest!

Handling Shadow DOM in Cypress

So far, you have seen an issue accessing the elements under the Shadow DOM. In Cypress, there are various methods to access Shadow DOM elements. The upcoming section will elaborate on these methods, providing a comprehensive understanding of how to interact with Shadow DOM elements effectively.

Below, you will see different ways to handle Shadow DOM in Cypress.

Using the .shadow() method

Let’s take the same example and use the shadow() command to enter data in the Name and Email field.

Open the site https://www.lambdatest.com/selenium-playground/shadow-dom.
Enter data in the Username Field.
Enter data in the Email Field.
Enter data in the Password Field.
Enter data in the Confirm Password Field.

describe("Enter data in Fields Inside Shadow DOM Using shadow() method ", () => {
beforeEach(() => {
cy.visit("https://www.lambdatest.com/selenium-playground/shadow-dom");
});
it("Enter data in all Fields", () => {
cy.get("shadow-signup-form").shadow().find('input[name="username"]').type("Kailash", { for,ce: true });
cy.get("shadow-signup-form").shadow().find('input[name="email"]').type("lambdatest@qa.com", { force: true });
cy.get("shadow-signup-form").shadow().find('input[name="password"]').type("lambdatest@123");
cy.get("shadow-signup-form").shadow().find('input[name="confirm_password"]').type("lambdatest@123");
});
});

Code Walkthrough

Here’s what each part does:

describe(“Enter data in Fields Inside Shadow DOM Using shadow() method”, () => { … });:

This sets up a test suite with a description.

describe(“Enter data in Fields Inside Shadow DOM Using shadow() method “, () =>

beforeEach(() => { … });:

This is a hook that runs before each test case in the suite. In this case, it visits the specified web page before executing every test.

beforeEach(() => {
cy.visit("https://www.lambdatest.com/selenium-playground/shadow-dom");
});

it(“Enter data in all Fields”, () => { … });:

This is an individual test case with the description “Enter data in all Fields”. The test case is responsible for interacting with the elements inside the Shadow DOM and entering data into the specified fields.

it(“Enter data in all Fields”, () => {}

cy.get(“shadow-signup-form”).shadow();:

This line uses the cy.get() command to locate the Shadow DOM element with the tag name “shadow-signup-form”.

cy.get(“shadow-signup-form”).shadow().find();

.shadow().find(‘input[name=”username”]’);:

The .shadow() method is used to interact with elements inside the Shadow DOM, and find(‘input[name=”username”]’) is used to find the input field with the name “username”.

cy.get(“shadow-signup-form”).shadow().find(‘input[name=”username”]’);

.type(“Kailash”, { force: true });:

The .type() command is then used to simulate typing “Kailash” into this input field.

.type(“Kailash”, { force: true });

Similar lines follow for other input fields like Email, Password, and Confirm Password, where data is entered using the .type() command.

To access the input box within the Shadow DOM, we have used the .shadow() method. Once inside the shadow DOM, we can interact with the input box and enter the data in the ‘Username’, ’Email’, ‘Password’, and ‘Confirm Password’ fields.

Keep your data safe and secure by using our free online Base64 Encode. With our tool, you can easily convert any type of data into a secured Base64 string. Try it now!

Adding a Flag in Config File

The second approach handles the Shadow DOM in Cypress by adding the flag ‘includeShadowDom’ in the configuration file.

Add the flag in the ‘cypress.config.js’ file. In the config file, you can add “includeShadowDom“: true.

The includeShadowDom: true configuration option in Cypress enables interaction with elements inside Shadow DOM. When you set includeShadowDom: true in your Cypress configuration, Cypress will enable support for Shadow DOM and allow you to interact with elements inside Shadow DOM using commands like cy.get() and cy.find().

const { defineConfig } = require("cypress");
module.exports = defineConfig({
"includeShadowDom": true,
e2e: {
setupNodeEvents(on, config) {
},
},
});

Let’s write the code. Here, we are not using the .shadow() command.

describe("Enter data in Fields Inside Shadow DOM By enabling Flag “includeShadowDom”: true, ", () => {
beforeEach(() => {
cy.visit("https://www.lambdatest.com/selenium-playground/shadow-dom");
});
it("Enter data in Fields Which are Inside the Shadow DOM ", () => {
cy.visit("https://www.lambdatest.com/selenium-playground/shadow-dom");
cy.get('[name="username"]').type("LambdaTest", { force: true });
cy.get('[name="email"]').eq(0).type("LambdaTest@qa.com", { force: true });
cy.get('[name="password"]').type("LambdaTest123", { force: true });
cy.get('[name="confirm_password"]').type("LambdaTest123", { force: true });
});
});

Adding Flag with Specific Command

The third approach is to handle the Shadow DOM in Cypress by adding the ‘includeShadowDom’ flag within specific commands.

In the third approach, instead of setting the ‘includeShadowDom’ flag globally, a more flexible approach is to include it within specific commands. This allows for finer control, enabling us to specify whether to include Shadow DOM per command.

describe("Enter data in Fields Inside Shadow DOM By adding Flag in commands “includeShadowDom”: true, ", () => {
beforeEach(() => {
cy.visit("https://www.lambdatest.com/selenium-playground/shadow-dom");
});
it("Enter data in Fields Which are Inside the Shadow DOM ", () => {
cy.get("shadow-signup-form").find('input[name="username"]',{ includeShadowDom: true }).type("Kailash", { force: true });
cy.get("shadow-signup-form").find('input[name="email"]',{ includeShadowDom: true }).type("lambdatest@qa.com", { force: true });
cy.get("shadow-signup-form").find('input[name="password"]',{ includeShadowDom: true }).type("lambdatest@123");
cy.get("shadow-signup-form").find('input[name="confirm_password"]',{ includeShadowDom: true }).type("lambdatest@123");
});
});

How to Automate Shadow DOM on Cloud?

Handling Shadow DOM in Cypress on the cloud is crucial for comprehensive and accurate testing of modern web applications. The increasing trend of web applications utilizing Shadow DOM for encapsulating styles and functionality necessitates robust testing mechanisms.

As cloud testing environments like LambdaTest gain prominence, it becomes imperative to validate that the infrastructure supports the intricacies of Shadow DOM testing. This ensures that applications leveraging Shadow DOM can be thoroughly tested in cloud-based environments, guaranteeing the reliability and functionality of the application in real-world scenarios.

LambdaTest is an AI-based test execution and orchestration platform that offers over 3000 real browsers and operating systems to help you automate Shadow DOM in Cypress on the cloud. You can accelerate your Cypress testing with Java and reduce test execution time by multiple folds by running parallel tests on Cypress Cloud across multiple browsers and OS configurations.

Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around automated testing, Cypress E2E testing, and more.

As we will execute the test cases on the LambdaTest platform, we must configure our tests for the LambdaTest cloud grid.

Test native, hybrid, and web apps on any mobile OS with our free Android emulator online. Sign up to optimize app performance.

Prerequisite:

You already have an account on LambdaTest.
You have an access token to run test cases on LambdaTest.

Configuring Cypress test on LambdaTest

Step 1: Install the CLI

The command-line interface of LambdaTest enables us to execute your Cypress tests on LambdaTest. Use the Cypress CLI command via npm as shown below

npm install -g lambdatest-cypress-cli

Step 2: Generate lambdatest-config.json

Under the root folder, configure the browsers we want to run the tests. Use the init command to generate a sample lambdatest-config.json file or create one from scratch. Use the below command

lambdatest-cypress init

In the generated lambdatest-config.json file, pass the information below. Fill in the required values in the section lambdatest_auth, browsers, and run_settings to run your tests.

In the file below, we pass three browsers (Chrome, Firefox, and Electron) and run the test case in two browsers simultaneously.

{
"lambdatest_auth": {
"username": "Enter username",
"access_key": "enter access key"
},
"browsers": [
{
"browser": "Chrome",
"platform": "Windows 10",
"versions": [
"latest-1"
]
},
{
"browser": "Firefox",
"platform": "Windows 10",
"versions": [
"latest-1"
]
}
],
"run_settings": {
"build_name": "Cypress With Shadow DOM Example ",
"parallels": 2,
"specs": "./cypress/e2e/shadowDom/*.cy.js",
"ignore_files": "",
"feature_file_suppport": false,
"network": true,
"headless": false,
"reporter_config_file": "",
"npm_dependencies": {
"cypress": "13.3.0"
}
},
"tunnel_settings": {
"tunnel": false,
"tunnel_name": null
}
}

Run the below command to execute the test case on the LambdaTest.

lambdatest-cypress run — sync=true

As we run the above command, test execution starts, and test cases are run in parallel on the LambdaTest platform.

seamlessly test your mobile applications, websites,and web apps on mobile browsers and mobile devices Try Mobile Emulator Online.

Test case execution

As we execute the test cases in the screenshot below, both test cases start executing in browsers (Chrome, Firefox) parallelly, and we can see the detailed report in the LambdaTest dashboard.

LambdaTest Dashboard offers users a convenient and intuitive interface to oversee test results, review test outcomes, and utilize various platform features. It enables live interactive testing, offering users a real-time view of the website or web application they are testing on a specific browser and operating system.

The screenshot below shows the test case starts executing in browsers (Chrome, Firefox).

The screenshot below shows that test cases are passed in the browser (Chrome, Firefox).

Here is the console log of executed test cases in the Chrome browser. You can see that three of the test cases are passing in LambdaTest Grid.

Here is the console log of executed test cases in the Firefox browser. You can see that three test cases passed on the LambdaTest Grid.

Conclusion

In this Cypress tutorial on handling Shadow DOM in Cypress, we’ve delved into the challenges of handling elements inside Shadow DOM, shedding light on the complexities of interacting with encapsulated components. We’ve explored various approaches and techniques to handle elements within the Shadow DOM effectively using Cypress.

Furthermore, we’ve discussed the integration of LambdaTest, an AI-powered test orchestration and execution platform, and how it enhances the capabilities of Cypress automation. By seamlessly running our Cypress tests across different browser versions and platforms, we ensure our applications’ compatibility and reliability in diverse environments. This integration empowers us to deliver high-quality web experiences to users across the digital landscape.

Perform browser automation testing on the most powerful cloud infrastructure. Leverage LambdaTest automation testing for faster, reliable and scalable experience on cloud.

Frequently Asked Questions (FAQs)

What is shadow DOM used for?

The Shadow DOM (Document Object Model) is a web standard that encapsulates styles, markup, and behavior within a scoped and isolated DOM subtree. It is primarily used to solve issues related to styling and the potential clash of CSS styles and JavaScript code in large and complex web applications. Here are some key purposes and use cases for the Shadow DOM

What is this shadowRoot?

In the context of the Shadow DOM (Document Object Model), shadowRoot is a property of an element that provides access to its own encapsulated subtree. The *shadowRoot *property refers to the root of the Shadow DOM subtree associated with a specific element.

How to Use Cypress in Headless Mode

Kailash Pathak — Thu, 30 Nov 2023 09:20:37 +0000

Tests are often carried out on real browsers to test the actual user experience. This approach ensures that the web application or site is examined in the real-world environment it is intended for, enabling testers to identify and address any issues that may impact user satisfaction and functionality. Testing on real browsers helps detect discrepancies that might not be apparent in simulated or emulated environments, ultimately leading to a more accurate assessment of the user experience.

However, running tests on a real browser can be slow because the browser needs to start up and load each web page before the tests can run, which can take a significant amount of time.

Additionally, running tests on a real browser can consume a lot of memory and other system resources, slowing down other processes and making the test environment less stable. This is why many developers opt to use headless browsers, which can simulate the behavior of a real browser without actually running the full application.

Some common issues when performing UI testing with a web browser include:

Flakiness: Tests may randomly fail or pass due to elements not loading correctly or other unpredictable behavior.
Slow performance: Running tests on browser instances can be slow and time-consuming, especially if there are many tests or if the tests are running on multiple browsers.
False negatives/positives: Sometimes, the tests may fail or pass incorrectly due to timing, network connectivity, or race conditions.
Test environment setup: Setting up the test environment, including installing the necessary browsers and drivers, can be challenging and time-consuming.
Page load time: Page load time is the time that passes between the browser sending the request to the server and the page fully loading. Sometimes, even if we have a good infrastructure, the page takes too long to load, and it can cause UI tests to fail or produce unreliable results.

This is where headless browsers come into the picture. In web browsers, headless mode refers to running a browser instance without opening a visual window. This can be useful for automated testing or running a browser programmatically as part of a larger system.

Most modern web browsers, including Chrome, Firefox, and WebKit, support headless mode. Headless testing can be faster and less resource-intensive than UI testing, as it does not require a real device or a simulation of the real environment.

You can perform headless browser testing using Cypress on a cloud-based Grid that supports using Cypress in headless mode. This means that you can perform Cypress testing in a browser environment without the need to have a GUI visible.

In this tutorial, you will learn how to run tests using Cypress in headless mode on popular browsers like Chrome, Firefox, and WebKit.

Perform live mobile website tests on different devices with LT Browser 2.0. test website on all device s*and tablet viewports and debug UI issues on the go across 50+ device viewports!*

Why use Headless Browser Testing?

When conducting end-to-end tests with a headless browser, the application’s user interface won’t be loaded by the browser. As a result, everything operates more quickly, and there is less risk of instability because the tests immediately interact with the website. Your tests become quicker, more accurate, and more effective.

There are several reasons why you might want to run Cypress in headless mode:

Speed: Headless browsers are often faster and use fewer resources than traditional browsers because they do not have to render the GUI. This can be useful for tasks requiring a lot of processing power or running tests on a server with limited resources.
Flexibility: Headless browsers can be run on various platforms, including Linux, Windows, and Mac. This makes running tests on different environments easy, which can help ensure that your website (or web app) works as expected on various devices and operating systems.
Cost-effectiveness: Headless browser testing is cost-effective as it eliminates the need for expensive hardware and software to run tests.
Automation: Headless browsers allow you to perform automated or repeatable tasks without interacting manually with the GUI. This can be particularly useful for tasks such as testing web applications or automating interactions on elements in any website.
Server-side rendering: Headless browsers can render web pages on the server side. This helps optimize web application performance and improve the end-user experience.
Simulating real user behavior: Headless browsers let developers simulate real user behavior on the website, which can help identify issues other methods may not catch.
Compatibility: Headless browsers can test the website’s compatibility with different browser versions.
Testing: Headless browsers can be used for web application testing, as they let you simulate a browser environment and make assertions about the behavior of your application.
Realistic testing: During headless testing, the browser operates in a manner akin to a genuine browser, actively loading all resources such as images, CSS, JavaScript, and more. This approach enables a more authentic testing experience, facilitating the detection of potential issues that might remain undetected when employing alternative testing methods.
CI/CD Integration: Headless tests reap more benefits when run with CI/CD tools because they consume fewer resources (i.e., CPU, RAM, etc.). Even in scenarios where the pipeline is executed in a remote environment, you can expect quicker results due to the inherently faster nature of headless testing.
Resource efficiency: Running tests without a GUI requires fewer resources, making headless browser testing more efficient.

Criteria for Choosing Headless Browsers

You should always choose a headless browser that is lightweight and uses very few resources so that you can run it in the background without hindering development work.

Many headless options are available, including tools to simulate multiple browsers and headless versions of well-known browsers like Chrome and Firefox. We have some factors to utilize in deciding which browsers are optimal for web development and testing.

Here are some factors to consider when selecting a headless browser for web testing:

Compatibility: Ensure the headless browser is compatible with your operating system and the programming language you plan to use for web testing.
Features: Consider the features important for your web testing, such as support for JavaScript, cookies, and web standards. Some headless browsers offer advanced features such as automatic form-filling, screenshot capture, and network emulation.
Performance: Consider the performance of the headless browser, including its speed and resource usage, as web testing can be resource-intensive when we have to test our application in multiple headless browsers.
Ease of use: Consider how easy it is to use the headless browser and whether it has good documentation and a supportive community.
Support: It’s important to choose a headless browser that is actively maintained and has a large community of users for support and troubleshooting.

Perform live mobile website tests on different devices with LT Browser 2.0. test website on mobile devices online free and tablet viewports and debug UI issues on the go across 50+ device viewports!

Popular Headless Browsers

The choice of using Cypress in headless mode depends entirely on the specific application requirements you are testing. Headless browser allows you to run the test cases in a headless (i.e., GUI-less) environment, which can be useful for running tests in a Continuous Integration (CI) environment or scripts that don’t require a visible UI.

Here are some commonly used headless browsers (irrespective of whether the framework is being used for automated testing)

Firefox Headless
Chrome Headless
WebKit Headless
PhantomJS
HtmlUnit Browsers

Though I have listed all major headless browsers, it is important to note that Cypress supports Firefox, Chrome, and WebKit headless browsers.

Firefox headless mode

Firefox headless mode is a web browser that allows you to test the application without the head. You cannot see anything while accessing any website using a headless browser. The application, however, operates in the background, and you can monitor the execution result once the test cases have finished running.

Firefox headless mode can be an effective option for automating web browsing tasks using Cypress. By running Firefox using Cypress in headless mode, you can interact with the browser as a regular user.

Chrome headless mode

Google’s Chrome team included headless Chrome mode in their browser, making running a Chrome headless browser from the command line easier.

Running tests using Cypress in headless mode makes fast test case execution and eliminates the need for manual interaction with the browser during testing.

WebKit headless mode

WebKit is an open-source web browser engine developed by Apple and used in the Safari browser. The headless mode of WebKit is a feature that allows the engine to run without a browser.

You can run tests on WebKit using Cypress in headless mode. To run Cypress test cases in WebKit, we must do some config settings and add the dependency. Add experimentalWebKitSupport: true in the cypress.config.js file to enable the experiment. Add dependency using the command to install the playwright-webkit NPM package in your repo to acquire WebKit: npm install –save-dev playwright-webkit.

Explore the evolution of Apple’s iOS! From iPhone OS to the latest iOS 16, dive into the journey that powers ios mobile device- iPhones, iPod Touches, and iPads. Uncover the history and future of this iconic operating system!

PhantomJS headless mode

PhantomJS is a popular solution for running browser-based unit tests in a headless system like a continuous integration environment since it provides a JavaScript API that enables automated navigation, screenshots, user behavior, and assertions.

Additionally, PhantomJS can be used to automate tasks such as filling out forms, clicking buttons, and navigating pages, which can be useful for functional and regression testing.

Some common use cases include:

PhantomJS can interact with web pages similarly to a web browser, allowing developers to automate tasks such as filling out forms, clicking buttons, and navigating between pages.
It can extract data from web pages, such as scraping product prices from an eCommerce site or extracting data from a table on a web page.
PhantomJS can generate screenshots or PDFs of web pages, which can help create reports or test a website’s appearance on different devices and screen resolutions.

HtmlUnit headless mode

HtmlUnit is a Java-based headless browser that allows developers to automate web page interactions. It can be controlled programmatically, allowing developers to simulate a user navigating a website and interacting with its elements, such as clicking buttons and filling out forms. HtmlUnit supports JavaScript and can work with various web standards, making it a versatile tool for web development and testing.

It can be integrated with popular testing frameworks such as JUnit and TestNG, allowing developers to write tests in Java and run them in HtmlUnit.

Additionally, HtmlUnit can be useful for testing web applications by simulating interactions with the web page and checking the resulting page source or DOM.

Use case in software testing using HtmlUnit headless browser:

Developers could use HtmlUnit to simulate a user logging into a web application by navigating to the login page, filling out the login form, and submitting it.
You can use HtmlUnit to navigate to various web application pages, interacting with elements such as buttons and links and asserting that the expected results occur.

As mentioned, Cypress supports Firefox, Chrome, and WebKit headless browsers. Hence, I would be demonstrating Cypress headless testing on the said browsers.

**Mobile device test and website on real iOS and Android devices hosted on the cloud. LambdaTest is a convenient, cost-effective and centralised solution for running realtime and Automated test on real device cloud.**

Testing with Cypress in Headless Mode

Before explaining how to run the test cases in headless mode in Cypress, let’s set up a Cypress project first.

To explain how we can run test cases in headless mode in Cypress, I will test a typical eCommerce site: LambdaTest eCommerce Playground.

Implementation Test Scenario

In this Cypress tutorial, we are using the below example to run the Cypress test case in a headless browser in Local Grid and LambdaTest Grid.

Test Scenario:

Open the Site https://ecommerce-playground.lambdatest.io/index.php?route=account/login.
Enter the email address.
Enter the password.
Click on the Login button.
Click on the ‘All Categories’ drop-down.
Enter the product to search.
Search the product.
Verify the correct product is searched.

Setting up Cypress

You can establish a new Cypress project by following the instructions below:

Step 1: Create a folder and generate package.json.

Create a project by Cypress_Headless.
Create a package.json file using the npm init command.

Step 2: Install Cypress

Run this command in the newly created folder to install Cypress.

npm install cypress — save-dev

yarn add cypress — dev

Cypress will be installed locally as a dev dependency for your project.

**Note: **Cypress version 12.3.0 is installed, as shown below. At the time of writing this blog, the most recent version of Cypress is 12.3.0

{
 "name": "cypress_headless",
 "version": "1.0.0",
 "description": "",
 "main": "index.js",
 "scripts": {
   "test": "echo \"Error: no test specified\" && exit 1"
 },
 "author": "Kailash Pathak",
 "license": "ISC",
 "dependencies": {
   "cypress": "^12.3.0"
 }
}

Stop using the same password for everything! Create strong and unique passwords that are difficult to guess with our Random Password Generator. Try it now!

Different ways to run Cypress tests in a headless browser

There are various ways of executing the Cypress test cases in headless browser mode.

To run all the test cases of the e2e folder in headless mode, use the yarn cypress run command. This command will run all the test cases under the e2e folder.
To run the particular .spec file in the headless mode, you can run the command yarn cypress run –spec cypress/e2e/example.cy.js.
Another way of running the test cases in headless mode is by adding scripts to the package.json. To run all test cases, we must run the command yarn run cy:run in the terminal. This command will execute all the test cases in headless mode.

{
"name": "cypress_headless",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"cy:run": "yarn cypress run"
},
"author": "<>",
"license": "ISC",
"dependencies": {
"cypress": "^12.3.0"
}
}
To run the test case on a particular browser in headless mode, we can add the script in package.json. To run all test cases in the Chrome browser, use the yarn run cy:run:chrome command in the terminal. To run all test cases in the Firefox browser, use the command yarn run cy:run:firefox in the terminal. To run all test cases in the Electron browser, use the command yarn run cy:run:electron in the terminal.

"name": "cypress_headless",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"cy:run:chrome": “yarn cypress run --browser chrome --headless"
"cy:run:firefox": “yarn cypress run --browser firefox --headless"
"cy:run:electron": “yarn cypress run --browser electron --headless"
},
"author": "<>",
"license": "ISC",
"dependencies": {
"cypress": "^12.3.0"
}
}
Another way to run the Cypress test cases in headless mode is running the test cases in the CI/CD pipeline. Below is an example of GitHub Action. Here, you can see we are executing Cypress test cases in the container with the Chrome browser.

name: Cypress Tests
on: [push]
jobs:
cypress-run:
runs-on: ubuntu-latest
container: cypress/browsers:node12.18.3-chrome87-ff82
steps:
- name: Checkout
uses: actions/checkout@v2
```
 # Install NPM
 # and run all Cypress tests
 - name: Cypress run
   uses: cypress-io/github-action@v4
   with:
     # Specify the Browser
     browser: chrome
```
Generate custom QR codes for your business or personal needs with our fast and easy-to-use QR code generator online tool in seconds. Try it now!

Folder Structure

The default folder structure for Cypress is displayed below. Under the “e2e” subdirectory, test cases can be created.

Let’s create test cases under the folder Cypress_Headless -> e2e. Create a .spec file with the name login_searchproduct.cy.js.

Create a login_searchproduct.spec.js file with the script below. This includes logging into the application and conducting a product search. Verify the right product should be displayed after the search.

/// <reference types="cypress" />
context("GIVEN Browser is already open  ", { testIsolation: false }, () => {
 it("WHEN User Open the Url", () => {
   cy.visit(
     "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
   );
 });
 it("AND Login into the application", () => {
   cy.get('[id="input-email"]').type("lambdatest@yopmail.com");
   cy.get('[id="input-password"]').type("lambdatest");
   cy.get('[type="submit"]').eq(0).click();
 });
 it("AND Click On All Categories drop down and Search the Product", () => {
   cy.get('[data-toggle="dropdown"]').eq(0).click();
   cy.contains("Laptops").click({ force: true });
   cy.get('[name="search"]').eq(0).type("Apple").should("have.value", "Apple");
   cy.get('[type="submit"]').eq(0).click();
 });
 it("THEN Verify Correct Product with name'iPod Shuffle' should display after Search ", () => {
   cy.contains("iPod Shuffle");
 });
});

Need to know how many characters are in your text? Get an accurate characters count in your text with our free online tool. Try it now and see how easy it is!

Code Walkthrough
In the above code snippet, we have opened the target URL using cy.visit(), and second, it() block is used to log in to the application by entering email and password.

In the third, it() block clicks on the ‘All Categories’ drop down and searches for the product., Finally, the last it() block is used to verify the searched product.

In the below screenshot, you can see how we can inspect the element. We have located the element by id for the email field.

cy.get(‘[id=”input-email”]’).type(“lambdatest@yopmail.com”);

Now, let’s run the above test scenario in headless browsers. We will run the test cases first locally, then we will run the same scenario on the LambdaTest Cypress cloud.

Cypress Headless Testing on Local Grid

Running tests on Chrome using Cypress in Headless Mode

Headless Chrome is a web browser that can run automated tests without opening a Chrome window. This empowers you to create tests capable of mimicking user interactions with your web application and verifying that the application functions as intended.

Run the above scenario locally in headless mode using Chrome using the below command.

yarn cypress run — browser chrome — headless

As we run the above command, test cases start executing locally in the Chrome headless mode.

Accurately count the number of words in your text with our easy-to-use word count tool. Perfect for meeting word count requirements. Try it out now for free!

Running tests on Firefox using Cypress in Headless Mode

To run the Cypress test cases in Firefox’s headless browser, you have to run the below command, which will run in the background, and finally, you will get the Pass/Fail result in the form of a report.

Run the above scenario locally in headless mode using Firefox using the below command.

yarn cypress run — browser firefox — headless

As we run the above command, test cases start executing locally in the Firefox headless mode.

Running tests on WebKit using Cypress in Headless Mode

Run the above scenario locally in headless mode using WebKit using the below command

yarn cypress run — browser webkit — headless

As we run the above command, test cases start executing locally in WebKit headless mode.

Cypress Headless Testing on Cloud Grid

In this section, you will find how to perform Cypress parallel testing on a cloud grid like LambdaTest.

LambdaTest is an AI-powered test orchestration and execution platform that lets you perform Cypress automation using headless mode across 40+ browser versions on the cloud. You can also run the Cypress test on the cloud parallel to the browser (Chrome, Firefox, and WebKit).

Subscribe to the LambdaTest YouTube Channel for the latest updates on tutorials around Selenium testing, Cypress e2e testing, Appium, and more.

Before running the test case in LambdaTest Grid, we have to do the set-up for LambdaTest. Below are some steps for setup.

Get plain text from XML documents. Simply copy and paste your XML data to extract text using our online free Extract Text from XML tool. Give it a try now!

Prerequisite to setup LambdaTest for test cases execution

You already signed up for LambdaTest
You have an access token to run test cases on LambdaTest.

Setup LambdaTest for Cypress test case execution

Step 1: Install the CLI

Install the LambdaTest using Cypress CLI command via npm. The command-line interface of LambdaTest enables us to execute your Cypress tests on LambdaTest.

npm install -g lambdatest-cypress-cli

Step 2: Generate lambdatest-config.json

Under the root folder, configure the browsers we want to run the tests. Use the init command to generate a sample lambdatest-config.json file or create one from scratch. Use the below command.

lambdatest-cypress init

In the generated lambdatest-config.json file, pass the below information. Fill in the required values in the section lambdatest_auth, browsers, and run_settings to run your tests.

In the below file, you can see we are passing three browsers (Chrome, Firefox, and Electron) and running the test case in two browsers simultaneously.

{
 "lambdatest_auth": {
   "username": "<>",
   "access_key": "<>"
 },
 "browsers": [
   {
     "browser": "Chrome",
     "platform": "Windows 10",
     "versions": ["latest-1"]
   },
   {
     "browser": "Firefox",
     "platform": "Windows 10",
     "versions": ["latest"]
   },
   {
     "browser": "Electron",
     "platform": "Windows 10",
     "versions": ["latest"]
   }
 ],
 "run_settings": {
   "build_name": "Headless Browser Testing build-name",
   "parallels": 2,
   "specs": "./cypress/e2e/*.cy.js",
   "ignore_files": "",
   "network": true,
   "headless": true,
   "npm_dependencies": {
     "cypress": "12.3.0"
   }
 },
 "tunnel_settings": {
   "tunnel": false,
   "tunnel_name": null
 }
}

Run the below command to execute the test case on LambdaTest.

lambdatest-cypress run — sync=true

As we run the above command, test case execution starts locally and parallelly on the LambdaTest platform.

LambdaTest Dashboard

The LambdaTest Dashboard provides a user-friendly interface for users to manage their test sessions, view test results, and access other platform features. It also allows users to perform live interactive testing by providing a live view of the website or web application being tested on a particular browser and operating system combination.

In the below screen, test cases start running in two browsers (Chrome, Electron), and in one other browser (Firefox), test case execution is in queue.

Once the execution of the two test cases mentioned above is completed in either the Chrome or Electron browser, the subsequent test case enters a queue. It initiates its execution in the Firefox browser. This transition is visually represented in the screenshot below.

Here is the console log of executed test cases in the Firefox browser. You can see all test cases are passing in LambdaTest Grid.

Here is the console log of executed test cases in the Chrome browser. You can see all test cases are passing in LambdaTest Grid.

As indicated in the console log displayed below, the test cases have successfully passed when executed in the Electron browser. Furthermore, it’s worth noting that all test cases exhibit successful outcomes within the LambdaTest Grid.

Are you ready to elevate your Cypress automation proficiency? Join the Cypress 101 certification program, crafted for developers and testers seeking to deepen their expertise in Cypress test automation. Gain advanced insights, polish your skills, and unlock many opportunities along your test automation journey.

Keep your JavaScript code safe from syntax errors with our free online JS Escape tool by quickly and easily converting special characters in your JavaScript.

Wrapping up

Using a headless browser, you can run the test cases without a graphical user interface (GUI) that allows developers to run automated tests, web scraping, and other tasks without visual browser representation. LambdaTest is an AI-powered test orchestration and execution platform enabling developers to perform Cypress UI automation across a diverse spectrum of browsers and operating systems using a headless browser. This empowers developers to thoroughly assess their websites and web applications across many configurations, all while eliminating the requirement for costly hardware and software investments.

Frequently Asked Questions (FAQs)

What is Cypress in headless mode?

Cypress headless mode is a feature of the Cypress testing framework that allows you to run tests without a visible browser UI. In Cypress headless mode, the test runs in the background without rendering a graphical user interface for the browser being used for testing. This is particularly useful for automated testing in CI/CD pipelines or when you simply want to run tests without the overhead of a visible browser window.

What is the difference between headless and headed mode in Cypress?

The difference between headless and headed mode in Cypress lies in the visibility of the browser user interface during test execution. In headed mode, Cypress displays a graphical user interface of the browser, allowing developers and testers to visually inspect the web page, interact with it manually, and observe test execution in real time. This mode is useful for debugging and development.

Conversely, Cypress headless mode runs tests without a visible browser UI, making it ideal for automated testing scenarios, especially in continuous integration (CI) environments. Since there’s no UI rendering, Cypress headless mode offers faster test execution and greater efficiency, making it well-suited for batch test runs where human interaction with the browser is unnecessary. The choice between the two modes depends on the testing context and whether manual interaction or automation efficiency is the primary focus.

Is Cypress headless faster?

Yes, Cypress in headless mode is typically faster than running it in headed mode with a visible browser UI. The main reason for this speed difference is that in headless mode, there is no graphical user interface to render, which reduces the computational overhead and allows the tests to execute more efficiently.

In headless mode, Cypress runs the tests in the background, and the absence of a visible browser window means fewer resources are dedicated to rendering and displaying the web page. As a result, test execution can be significantly faster, which is especially beneficial in automated testing scenarios such as continuous integration (CI) pipelines, where speed and efficiency are essential.

However, it’s important to note that the actual speed difference may vary depending on the complexity of the tests and the specific use case. For many automated testing scenarios, especially those involving many tests, Cypress in headless mode is preferred to maximize testing efficiency

How to Perform E2E Testing Using Cypress CLI and Test Runner

Kailash Pathak — Tue, 12 Sep 2023 06:43:09 +0000

End-to-End (E2E) testing is a software testing methodology that focuses on testing an application’s workflow from start to finish, simulating real user interactions, and verifying that all components of the system work together correctly.

To illustrate E2E testing, let’s consider a live scenario involving an eCommerce website. The goal is to test the entire purchasing process, from when a user adds items to the shopping cart until the order is successfully placed. We usually follow the below approach.

Test Setup: Ensure the testing environment is prepared with the latest version of the application and necessary test data.
Test Case/Automation script Preparation: Define test cases/scripts to cover the complete order placement process, including adding items to the cart, user authentication, shipping selection, payment processing, and order confirmation.
Test Execution: Begin the test by simulating user interactions, such as adding items to the cart, filling in user details, selecting shipping options, entering payment information, and confirming the order.
Test Completion: Review the test results, identify critical issues, and summarize the overall findings, including bugs, errors, or unexpected behavior.

Selenium WebdriverIO is Javascript based test automation framework built over nodeJs. Learn with this guide how to use webdriverIO to perform web automation testing.

By performing E2E testing in a live scenario like this, you can gain confidence in the reliability and functionality of the eCommerce website’s purchasing process.

Running E2E tests using Cypress CLI helps you configure test runs, generate reports, and integrate with other tools and services to streamline your testing process. It provides a command-line interface to manage and execute E2E tests efficiently. The Cypress CLI provides a comprehensive set of commands and features that empower developers and testers to perform robust and efficient E2E testing.

The other way to run E2E tests is using Cypress Test Runner, which provides an interactive graphical interface that allows developers and testers to run their tests, monitor their progress, and analyze the results in real-time. When using the Cypress Test Runner, you can select specific test files or test suites to execute and then observe the test execution step by step.

You will learn more about different ways of running tests in Cypress, i.e., using Cypress CLI and Test Runner in the later sections of this Cypress tutorial.

What is E2E Testing?

End-to-End (E2E) testing is a software testing strategy that focuses on verifying the complete flow of an application from start to finish. It aims to ensure that all system components, including user interfaces, APIs, databases, and integrations, work together properly and meet the desired functionality.

It is often performed after unit testing and integration testing, which test individual components and their interactions, respectively. By conducting E2E testing, the entire system is evaluated as a whole, simulating real-world user scenarios and ensuring that the application behaves as expected in a production-like environment.

The primary goal of E2E testing is to validate the application’s functionality, reliability, and performance from end to end. It helps uncover any defects or issues arising from the interactions between different components. By thoroughly testing the application’s complete flow, E2E testing provides confidence that the system works as intended and meets the requirements of the end-users or business.

Let’s take an example of a simple E2E test scenario where you login into LambdaTest’s eCommerce Playground with valid credentials. After login subscribe to the newsletter and verify whether the subscription was successful.

Which are the most wanted automation testing tools in 2023 that have climbed the top of the ladder so far? Let’s take a look.

Why Cypress for End-to-End Testing?

E2E testing is a type of software testing that verifies the entire application from start to finish. This means that E2E tests simulate real user interactions with the application, ensuring that all of the application’s features work together as expected. Cypress is the best fit for E2E testing for several reasons:

Ease of Use

Cypress provides an intuitive and easy-to-use API, which makes it user-friendly and allows developers/testers to write tests quickly. Its syntax is straightforward, and the documentation is extensive and well-maintained.

Automatic waiting and real-time reloading

Cypress automatically waits for DOM elements to become available and actions to complete, eliminating the need for manual waits or timeouts. It also provides real-time reloading, which means developers/testers can see the impact of their code changes immediately during test execution.

Automatic screenshots and video recording

Cypress automatically captures screenshots and records videos during test runs. This is helpful for visual debugging and for documenting test failures, making it easier to understand and reproduce issues.

Built-in Test Runner

Cypress comes with a built-in Test Runner, which means there is no need to set up or configure additional tools or frameworks. The Test Runner provides a clear interface to view test results, manage test files, and execute tests with a simple command.

Active and supportive community

Cypress has a vibrant and active community of developers who contribute to its development and provide support. The official documentation is comprehensive and regularly updated, and there are numerous community-written tutorials, blog posts, and plugins available

Full control over the application

To understand Cypress E2E testing, let’s take a closer look at the test automation pyramid. We routinely do each level of testing listed in this pyramid while performing Cypress testing.

Deep dive to learn what is automation testing, its uasage, types and also gain insights on how to get started with automated testing.

Subscribe to the LambdaTest YouTube Channel to get the latest updates on tutorials around Selenium testing, Cypress e2e testing, Appium, and more.

Testing Pyramid Layers in Cypress

Cypress team introduced component testing with Cypress 10 that allows developers to test individual components quickly, regardless of their complexity. Component tests differ from E2E tests in that instead of visiting a URL to pull up an entire app; a component can be “mounted” and tested on its own.

In the context of Cypress, here’s how the testing pyramid can be applied:

Unit Tests

These tests focus on testing individual components or functions in isolation. In Cypress, you can use frameworks like Mocha or Jest to write unit tests for your JavaScript functions.

These tests are typically executed quickly and frequently, ensuring that each component of your application works as expected.

Component Tests

These tests verify the behavior of individual components or UI elements in your application. In Cypress, you can write component tests that interact with specific UI elements and verify their functionality.

These tests ensure that each component functions correctly within the application’s context.

Integration Tests

Integration tests focus on testing the interactions between different components or modules in your application. In Cypress, you can write integration tests that simulate user interactions and verify the integration of various components.

These tests ensure that the different parts of your application work together seamlessly.

End-to-End (E2E) Tests

These tests span the entirety of the application’s process, validating its behavior holistically. Within Cypress, E2E tests can be authored to replicate user actions, engage with the UI, and authenticate anticipated results.

Although these tests often demand more time for execution, they deliver a sense of assurance in the comprehensive functionality of your application.

To know more about component testing, let’s see the difference between end-to-end testing and component testing.

This blog discusses the most exciting features of 13 best automation testing frameworks in 2021.

Here is an example of Cypress E2E test scenario:

Test Scenario

Visit the site

https://ecommerce-playground.lambdatest.io/index.php?route=account/login

Search with valid data and verify the search data should be displayed.
Search with invalid data and verify the message.

Implementation

In the following scenario, we will navigate to the website and perform searches using both valid and invalid data.

describe('Search  with valid and Invalid data' , () => {
 beforeEach(() => {
 cy.visit('https://ecommerce-playground.lambdatest.io/index.php?route=account/login')
 })
 it('Searches for the valid text  "Apple" and  verify the results', () => {
  // Enter the search data and submit the form
   cy.get('[name="search"]').eq(0).type('Apple')
   cy.get('.type-text').click()
   // Verify the search results
   cy.url().should('include', 'search=Apple')
   cy.contains('Search - Apple').should('be.visible')
   cy.get('.product-layout').should('have.length.gt', 0)
 })
 it('Displays message with no search results for invalid search term', () => {
   // Enter search term and verify returns no results and submit form
   cy.get('[name="search"]').eq(0).type('xyz')
   cy.get('.type-text').click()
   // Verify message for no search results
   cy.contains('There is no product that matches the search criteria.').should('be.visible')
 })
})

Let’s execute the test cases in Searchwith_validAndinvalid_data.cy.js.

Execution

Discover the 17 key benefits of automation testing, which will help you decide whether this is the right call for your SDLC.

What is Cypress CLI (Command Line Interface)?

CLI stands for Command-Line Interface. It is a text-based interface used to interact with a computer operating system or software by typing commands instead of using a graphical user interface (GUI).

Typically, CLI commands consist of a command followed by optional parameters or arguments. The user enters the command, and the system responds with the requested action or provides feedback on the command’s execution. CLI is popular among developers and system administrators due to its efficiency, flexibility, and ability to automate tasks through scripts or batch files.

Some well-known examples of CLI interfaces include the Windows Command Prompt (cmd.exe), PowerShell (for Windows), the Unix/Linux shell (such as Bash), and the macOS Terminal (based on the Unix shell).

The Cypress CLI provides a set of commands that enable developers and testers to interact with the WebElements and control the Cypress testing framework from the command line. It allows you to initialize new Cypress projects, run tests, open the Cypress Test Runner, and perform various other testing-related tasks.

With the Cypress CLI, you can perform various tasks, including:

Opening the Cypress Test Runner: The CLI allows you to open the Cypress Test Runner, which provides a graphical user interface for running and debugging your tests. You can use this interface to select and execute individual test files or suites, view test results, and debug failing tests.
Running tests in headless mode: Using Cypress CLI, you can run Cypress test automation in headless mode, which means the tests run without displaying the graphical user interface of the Test Runner. This is useful for running tests in a Continuous Integration (CI) environment or as part of an automated test suite.
Running tests in different browsers: The Cypress CLI lets you specify the browser in which you want to run your Cypress tests. You can choose from popular browsers like Chrome, Firefox, or Electron or even specify custom browser configurations.
**Running tests in parallel: **If you have a large suite of tests, the Cypress CLI enables you to run Cypress parallel testing across multiple instances of Cypress. This can significantly reduce the overall test execution time.
Generating test reports: You can generate HTML or JSON reports for your test runs using the Cypress CLI. These reports provide detailed information about the test results, including passed and failed tests, execution times, and error messages.
Managing configuration options: The Cypress CLI allows you to configure various options for Cypress, such as specifying the test file patterns to include or exclude, setting environment variables, configuring plugins, and more.

This article on the Best UI Automation Testing Tools cover what is UI automated testing, challenges while performing UI testing, and top tools that can help you perform UI testing.

Here are some common commands we can run using Cypress CLI:

What is a Cypress Test Runner?

Cypress also comes with a built-in Test Runner GUI that provides an interactive interface for running and debugging tests. To launch the Test Runner, you can use the Cypress open command. This opens a Test Runner window where you can select and run individual tests, view test results, and debug your code.

The Cypress Test Runner operates directly in the browser and runs tests within it, enabling real-time visibility into the application under test. It offers a built-in time-traveling feature that allows developers to inspect and debug the application’s state at any point during the test execution. This makes it easier to troubleshoot and identify the causes of test failures.

Some key features of Cypress Test Runner include:

Interactive Test Runner: Cypress Test Runner has an interactive user interface that allows you to view the test execution in real time. You can see the commands being executed, their results, and any errors or failures. This live feedback makes it easy to identify and diagnose issues during test execution.
Time Travel: Cypress allows you to “time travel” through your application and see exactly what happens at each step of your test. You can pause the test execution, step forward or backward, and inspect the application’s state at any time.
Debugging with DevTools: Cypress integrates with the browser’s Developer Tools, allowing you to debug your application and tests directly from the Cypress Test Runner. You can set breakpoints, inspect variables, step through code, and interact with the application while the test is running.
Real-Time Reloads: Cypress automatically detects changes made to the test code and reloads them in the Test Runner interface. This live reload functionality provides a seamless development experience, allowing developers to see the immediate effects of their code changes without manually reloading the page.
Network Stubbing and Spying: Cypress allows developers to stub or intercept network requests made by the application. This enables you to simulate different network scenarios, control the responses from APIs, and test edge cases.

Below is the screenshot of Cypress Runner, which opens when the user runs the command ‘yarn cypress open’.

Test native, hybrid, and web apps on any mobile OS with our free online emulator Android. Sign up to optimize app performance.

Running Test Cases in Cypress

When it comes to running Cypress test cases, there are different approaches you can take depending on your specific requirements and testing environment.

Here we will be discussing how you can run Cypress test cases using:

Cypress CLI
Cypress Test Runner

The Cypress CLI provides a straightforward way to run Cypress automation from the command line. You can use the cypress run command to run your tests in headless mode or cypress open to run them in interactive mode. The Cypress CLI also offers various options and flags to customize the test run, such as specifying specific test files, setting environment variables, and generating test reports.

Now let’s take some examples to execute the test cases in Cypress CLI.

Test Scenario

Visit the Site https://ecommerce-playground.lambdatest.io/index.php?route=account/login
Login into the site valid credential.
Do subscribe to the newsletter.
Verify newsletter is successfully subscribed.

Implementation

Let’s create a new folder under the e2e folder named “demoCypressCLIRunner” to perform Cypress UI testing.

Create the first test spec to check the login feature for the site with the name subscriptionScenario..cy.js under the folder ‘demoCypressCLIRunner’.

For demo purposes, we are using the LambdaTest eCommerce Playground site.

Use Case

describe('Login and Subscribe', () => {
 it('Logs in and subscribes to newsletter', () => {
   // Visit the web site
   cy.visit('https://ecommerce-playground.lambdatest.io/index.php?route=account/login')


// Click on login button
 cy.get('[value="Login"]').click()
// Enter the valid email and password
cy.get('#input-email').type('lambdatestnew@yopmail.com')
cy.get('#input-password').type('Lambda123')


// Click on login button
cy.get('[value="Login"]').click()


// Verify user logged in successfully
cy.url().should('include', 'index.php?route=account/account')
cy.contains('My Account').should('be.visible')


// Subscribe the newsletter
 cy.contains('Newsletter').click()
 cy.get('#input-newsletter-yes').click({force:true})
 cy.get('[value="Continue"]').click()


 // Verify the subscription success message
   cy.get('.alert-success').should('contain', 'Success: Your newsletter subscription has been successfully updated!')
 })
})

Test native, hybrid, and web apps on any mobile OS with our free online android emulator. Sign up to optimize app performance.

How to Run Test Cases in CLI?

There are different ways to run the Cypress test cases in CLI.

Command 1:

Run all Cypress tests using Cypress CLI in the Electron default headless browser.

Output

All the tests are in headless mode in the default browser Electron. The Cypress command ran successfully, and our tests got executed.

Now, let’s understand some important aspects of this execution marked by the numbered tickets:

Command used to run all the test files present under the “e2e” folder.
Test cases started with Cypress, Browser, and Node versions with the number of test .spec files.
Test cases are executed one by one in the 3rd sticker. It shows that the first .spec file is passed.
Recording of all the test cases is saved under the ‘videos’ folder, which greatly helps during debugging.
Final test cases execution result report with parameters like Tests, Passing Test, Failing Test, Pending, and Skipped Tests.

A comprehensive end-to-end Testing tutorial that covers what E2E Testing is, its importance, benefits, and how to perform it with real-time examples.

Command 2:

Run the particular test in headless mode in the default browser Electron.

To run specific spec files from the list of test cases under the e2e folder, we can mention the path using “–spec” along with the “cypress run” command.

Output

In the output, we can see the test case execution report of a particular .spec.

Command 3:

Run all the tests in Cypress CLI to run tests in Chrome (Headless Mode).

Output

In the output, we can see the test case execution report of all test cases in the Chrome browser.

Command 4:

Run a particular test case in Cypress CLI to run tests in (Headless Mode).

Output

In the output, we can see the test case execution report of a particular .spec in the Chrome browser.

A comprehensive end-to-end Testing tutorial that covers what e2e Testing is, its importance, benefits, and how to perform it with real-time examples.
Let’s take one more scenario.

Test Scenario

Visit the site

https://ecommerce-playground.lambdatest.io/index.php?route=account/login

Search with valid data and verify the search data should be displayed.
Search with invalid data and verify the message.

Implementation

Create the second test case with the name “Searchwith_validAndinvalid_data.cy.js” under the LambdaTest folder.

In the below test case, we are covering the search with valid and invalid data and verifying the search result.

Use Case

Open the site and search with valid and invalid data.

describe('Search  with valid and Invalid data' , () => {
 beforeEach(() => {
 cy.visit('https://ecommerce-playground.lambdatest.io/index.php?route=account/login')
 })
 it('Searches for the valid text  "Apple" and  verify the results', () => {
  // Enter the search data and submit the form
   cy.get('[name="search"]').eq(0).type('Apple')
   cy.get('.type-text').click()
   // Verify the search results
   cy.url().should('include', 'search=Apple')
   cy.contains('Search - Apple').should('be.visible')
   cy.get('.product-layout').should('have.length.gt', 0)
 })
 it('Displays message with no search results for invalid search term', () => {
   // Enter search term and verify returns no results and submit form
   cy.get('[name="search"]').eq(0).type('xyz')
   cy.get('.type-text').click()
   // Verify message for no search results
   cy.contains('There is no product that matches the search criteria.').should('be.visible')
 })
})

Command 1:

Run all the tests in Cypress CLI in default browser Electron (Headless Mode).

yarn cypress run

Output

Command 2:

Run a particular test in Cypress CLI to run tests in Chrome (Headless Mode).

yarn cypress run --spec cypress/e2e/demoCypressCLIRunner/Searchwith_validAndinvalid_data.cy.js
Chrome

Output

Command 3:

Run all test cases in Cypress CLI to run tests in Chrome (Headless Mode).

yarn cypress run — headless — browser chrome

Output

Command 4:

Run particular test in headless mode in Chrome browser.

yarn cypress run - spec cypress/e2e/demoCypressCLIRunner/Searchwith_validAndinvalid_data.cy.js
Chrome

Output

In this Appium tutorial, learn about Appium and its benefits for mobile automation testing. Take a look at how Appium works and see how to perform Appium automation testing of your mobile applications.

How to Run Test Cases in Cypress Test Runner?

Cypress Test Runner provides a user interface (UI) that allows you to interact with and run your Cypress tests. After executing the appropriate command to start the Test Runner, the UI will be launched. From there, you have several options for running your tests.

By default, Cypress will launch the Test Runner UI with its default browser, which is typically Electron. However, you can switch to a different browser by selecting it from the available options in the browser drop-down menu.

To run a single test, just enter the particular .spec name and execute the test case.

Another way to run a single test is to click on a specific test case, and it will start executing.

If you want to run the test case, run the command ‘yarn cypress open’, which will open the Cypress Test Runner from where you can execute the test cases.

Execution

Let’s execute both test cases Searchwith_validAndinvalid_data.cy.js and subscriptionScenario.cy.js in non headless mode using UI by passing –ui in command.

You can also leverage the potential of Cypress E2E testing on the cloud and run Cypress test cases over real browsers and OS combinations. AI-powered test orchestration and execution platforms like LambdaTest offer a scalable Cypress cloud to perform automation testing across 40+ real desktop browsers.

Ready to elevate your Cypress automation skills? Join our specialized Cypress 101 certification program tailored for developers and testers seeking to expand their proficiency in Cypress test automation. Gain advanced insights, hone your abilities, and unlock a world of opportunities on your journey in test automation.

A comprehensive Exploratory Testing tutorial that covers what Exploratory Testing is, its importance, benefits, and how to perform it with real-time examples.

Conclusion

With Cypress CLI, you can run tests from the command line, which helps integrate tests into your CI/CD pipelines or run them in headless environments.

On the other hand, Cypress Test Runner offers a range of features that enhance the testing experience. It provides a real-time view of your application as tests run, allowing you to see each step executed and the application’s response. This helps in debugging and understanding the test flow.

Frequently Asked Questions (FAQs)

How to run Cypress cmd?

1.Navigate to Your Project Directory: Open your command prompt or terminal and navigate to the root directory of your Cypress project.

2. Run the Command: Use the following command to execute Cypress tests:

npx cypress open

This command will open the Cypress Test Runner, allowing you to select and run your test files interactively.

If you want to run tests in headless mode (without the interactive Test Runner UI), you can use:

npx cypress run

3.Select the Test File: In the Test Runner, select the test file you want to run from the list of available test files.

Run Tests: Click on the test file name to run the tests within that file.

What is a Cypress command?

The “Cypress command” typically refers to the command-line interface (CLI) commands provided by the Cypress testing framework. These commands allow you to interact with Cypress, run tests, manage configurations, and perform various testing-related tasks. Some common Cypress commands include:

cypress open: Opens the Cypress Test Runner, providing an interactive interface to run and debug tests.
cypress run: Executes tests in headless mode, which is suitable for automated testing and integration with CI/CD pipelines.
cypress install: Installs the Cypress framework and its dependencies within your project.
cypress verify: Checks the installed version of Cypress and its compatibility with your project.
cypress –help: Displays the list of available commands and their descriptions.
cypress –version: Displays the currently installed version of Cypress.
cypress run –spec : Runs a specific test spec file.
cypress run –record: Records test runs in the Cypress Dashboard for insights and videos.
cypress run –parallel: Runs tests in parallel with a paid Cypress Dashboard plan.

These commands are executed in your terminal or command prompt and allow you to control various aspects of your testing workflow using the Cypress framework.

How To Use Cypress For File Upload and Download

Kailash Pathak — Tue, 11 Jul 2023 08:15:56 +0000

On web applications, downloading and uploading files are operations we normally do, mainly for activities like banking, social media platforms, etc. In an online banking system, customers may need to upload documents such as income statements, bank statements, or identification proofs as part of a loan application process. Also, banking applications have features from which customers can download account statements.

Similarly, social media platforms enable us to share photos, videos with our friends and followers. We upload these files from our devices to the social media platform, where they are stored and made accessible to others who can then download and view them.

If a web application does not have an upload/download feature, it means that users won’t be able to transfer files directly between their devices and the application’s server through the application’s interface. It can result in potential business losses and impact user experience.

Automation of uploading and downloading functionality involves automating the process of testing file transfer capabilities in a web application. It aims to efficiently and accurately validate the uploading and downloading features through automated scripts.

Uploading files is typically done using a file input element on a web page, and the selected file is sent to the server as part of an HTTP request. In Cypress, you can automate file uploads by simulating user interaction with the file input element and attaching a file to it using the .attach() command.

Downloading files is typically done by sending an HTTP request to the server and receiving a file as part of the response. In Cypress, you can automate file downloads by intercepting the HTTP response and saving the file to a specified location on the user’s computer using the .writeFile() command.

Considering the criticality of these operations (i.e., using download/upload) in many businesses (e.g., banking, social media, eCommerce, etc.), it becomes imperative to test these functionalities as a part of the automated CI/CD pipeline.

By the end of this Cypress tutorial, you will learn how to use Cypress for file upload and download.

So, let’s get started!

Get ready for your Mocha interview with our expert-curated list of Mocha interview questions tips. Impress your potential employer and land your dream job!

How to use Cypress for file upload?

Uploading files is a common scenario in web applications that allow users to upload their files. In the uploading files process, we select the file from the local machine to a web application during a test. Using Cypress for file upload involves testing adding a file with the below-supported format.

Images: JPEG (.jpg, .jpeg), PNG (.png), GIF (.gif).
Documents: PDF (.pdf), Microsoft Word (.doc, .docx), Microsoft Excel (.xls, .xlsx).
Videos: MP4 (.mp4), WebM (.webm), AVI (.avi), MOV (.mov)) to a web application using the Cypress testing framework.

Boost your testing skills with Pytest interview questions. Beginner, intermediate, and advanced levels covered. Prepare and excel in your interviews.!

There are multiple ways to use Cypress for file upload. Here are some common approaches:

Using Cypress for file upload with the selectFile().
Using Cypress for file upload with the cypress-file-upload plugin.

Using Cypress for file upload with the selectFile()

There are various ways of uploading files using the selectFile() command.

Using selectFile()

Before explaining uploading files using selectFile(), let’s learn about the command selectFile().

The selectFile() command in Cypress enables you to upload a single file, an array of files and simulate the selection of files with additional options. In Cypress, the selectFile() command allows you to interact with file input elements (e.g., <input type=”file“>)

Syntax

The selectFile() method takes multiple arguments, as shown below:

In Cypress, the selectFile() command can be used to imitate dragging a file or files into the browser, as well as selecting and uploading files to an HTML5 input element.

When you invoke the selectFile() command in Cypress for file upload, it opens a file selection dialog in the browser. You can then provide file paths or an array of file paths to the command to simulate the selection of files.

The selectFile() command in Cypress for file upload supports various file types for imitating file selection or upload actions in a browser or HTML5 input element. It can handle common file types such as:

Text files (e.g., .txt, .csv)
Image files (e.g., .jpg, .png, .gif)
Document files (e.g., .doc, .docx, .pdf)
Audio files (e.g., .mp3, .wav)
Video files (e.g., .mp4, .avi)

If you are getting started with Cypress and want to install Cypress, you can go through this blog that covers installing Cypress in detail. You can consider installing the latest version. However, the version at the time of writing this blog is 12.11.0.

The cy.selectFile(file) command lets you specify a file or files to be uploaded through an input element of type “file” on a web page.

OPERATION	COMMAND
Upload JSON File	cy.get(‘input[type=file]’).selectFile(‘file.json’)
Upload txt File	cy.get(‘input[type=file]’).selectFile(‘file.txt’)
Upload image file (jpg, png)	"cy.get(‘input[type=file]’).selectFile(‘image1.jpg’) cy.get(‘input[type=file]’).selectFile(‘image2.png’)"
Upload video file	cy.get(‘input[type=file]’).selectFile(video.mp4′)
Upload audio file	cy.get(‘input[type=file]’).selectFile(audio.mp3′)

Ace your QA interviews with our comprehensive guide on 60+ SpecFlow Interview Questions and Answers. Boost your BDD knowledge and showcase your SpecFlow expertise.

Options

The options parameter is an optional object that allows you to customize the behavior of the cy.selectFile(). In options, you can pass the following parameters.

PARAMETER

action	select	Switch modes. Valid values are select and drag-drop.
force	FALSE	Forces the action, disables waiting for actionability.
log	TRUE	Displays the command in the Command log.
timeout	defaultCommandTimeout	Time to wait for .selectFile() to resolve before timing out.
waitForAnimations	waitForAnimations	Whether to wait for elements to finish animating before executing the command.

Demo — Using Cypress for file upload using the selectFile()

Test Scenario

Visit the site: https://the-internet.herokuapp.com/upload.
Upload the .png file.
Click on the Submit button.
After submitting, verify the “File Uploaded” message.

In this example, we are uploading the image file using selectFile() with select mode. This command is used to select a file to upload to an input field. The command first selects the file input element using the cy.get() method with the input[type=file] selector.

Then, the selectFile() method is called on the selected element with the argument ‘image.png’. This will simulate selecting the file image.png in the file selection dialog that appears when a user clicks on the file input field.

Implementation

For demo purposes, I am taking the example from the site: https://the-internet.herokuapp.com/upload

it("Upload the file using .selectFile with select mode", () => {
   cy.visit("https://the-internet.herokuapp.com/upload");
   cy.get("#file-upload").selectFile("cypress/fixtures/images/nature_evening.png");
   cy.get("#file-submit").click();
   cy.get("#uploaded-files").contains("nature_evening.png");
   cy.get("h3", { timeout: 30000 }).should("have.text","File Uploaded!");
 });

Ace your Cypress interview with these 60+ Cypress interview questions. Boost you confidence and land your dream job with this comprehensive guide.

You can use the *cy.get() *command and pass in the Id of the element. For example, the following code would locate an element with the ID ‘file-upload.’

cy.get(“#file-upload”)

cy.get(“#file-submit”).

You can use the cy.get() command and pass in the Id of the element. For example, the following code would locate an element with the ID ‘file-submit’.

cy.get(“#uploaded-files”).

You can use the cy.get() command and pass in the Id of the element. For example, the following code would locate an element with the ID ‘uploaded-files’.

Code Walkthrough

We have kept the .png file under the images folder. After uploading the image, click on the upload button and verify the message “File Uploaded!”.

Step 1

It navigates to the specified URL, which is the file upload page of a web application.

Step 2

It selects a file for upload. The code targets the file input element with the ID “file-upload” and uses the .selectFile() command to specify the file path to be uploaded (“cypress/fixtures/images/nature_evening.png”).

Here’s 295+ Selenium Interview Questions with Answers that will help you boost your confidence in an Interview.

Step 3

This line clicks on the “file-submit” button to initiate the file upload process.

Step 4

It verifies that the uploaded file is displayed on the page. The code targets the element with the ID “uploaded-files” and checks if it contains the text “nature_evening.png.”

Step 5

This line waits for an < h3 > element to appear on the page (with a maximum timeout of 30 seconds) and asserts that its text content is “File Uploaded!”. This assertion ensures that the file upload operation was successful.

Output

If you are preparing for a Playwright automation interview, this list of Playwright interview questions can help you get a list of the most asked questions with detailed answers.

Uploading files using the command selectFile() and options

This command is used to select a file to upload to an input field using a drag-and-drop action. The command first selects the file input element using the cy.get() method with the input[type=file] selector.

Then, the selectFile() method is called on the selected element with two arguments. The first argument is image.png’, which is the name of the file you want to upload. The second argument is an options object with the action property set to ‘drag-drop’. This will simulate dragging and dropping the file onto the input field rather than using the file selection dialog.

Demo — Uploading files using the selectFile() and options

In this tutorial on Cypress for file upload, let’s look at the demonstration for uploading files using the selectFile() and options.

Visit the site: https://the-internet.herokuapp.com/upload.
Upload the .png file.
Click on the Submit button.
After submitting, verify the “File Uploaded” message.

Implementation

For demo purposes, I am taking the example from the site: https://the-internet.herokuapp.com/upload.

In the below example, the location of uploading the file is from the local system.

it("Upload the file using .selectFile with with drag and drop mode", () => {
   cy.visit("https://the-internet.herokuapp.com/upload");
   cy.get("#file-upload").selectFile("cypress/fixtures/images/nature_night.png", {action: "drag-drop"});
   cy.get("#file-submit").click();
   cy.get("#uploaded-files").contains("nature_night.png");
   cy.get("h3", { timeout: 30000 }).should("have.text","File Uploaded!");
 });

Code Walkthrough

Step 1

The cy.visit(“https://the-internet.herokuapp.com/upload”) command is used to navigate to the specified URL, which is the web application’s file upload page.

Here’s a list of 70 Cucumber Interview Questions and Answers that will help you boost your confidence in an Interview.

Step 2

It targets the file input element with the ID “file-upload” and uses the .selectFile() command to specify the file path to be uploaded (“cypress/fixtures/images/nature_night.png”).

Additionally, the {action: “drag-drop”} option indicates that the file should be selected using the drag-and-drop mode.

Step 3

Clicks on the “file-submit” button to initiate the file upload process.

Step 4

The cy.get(“#uploaded-files”).contains(“nature_night.png”) verifies that the uploaded file is displayed on the page. It targets the element with the ID “uploaded-files” and checks if it contains the text “nature_night.png”.

Step 5

The cy.get(“h3”, { timeout: 30000 }).should(“have.text”,”File Uploaded!”) waits for an < h3 > element to appear on the page (with a maximum timeout of 30 seconds) and asserts that its text content is “File Uploaded!”.

This assertion ensures that the file upload operation was successful.

The maximum file size that can be uploaded using the cy.selectFile() command in Cypress depends on the underlying browser. We can give a timeout with a particular command to handle if a file takes a long time to upload.

Output

Get ready for your BDD interview with 100+ BDD interview questions. Boost your confidence and impress your interviewer with this comprehensive guide covering principles & techniques

Uploading an array of files using the selectFile()

The command first selects the file input element using the cy.get() method with the input[type=file] selector.

Then, the selectFile() method is called on the selected element with the argument [imag1.png’, ‘image2.png’]. This will simulate selecting multiple files in the file selection dialog that appears when a user clicks on the file input field.

Demo — Uploading an array of files using the selectFile()

Test Scenario

Visit the site: https://postimages.org/.
Upload multiple .png files with the drag-drop option.
After upload, verify the text “Upload completed”.
After uploading, verify the title of all uploaded images.

Implementation

For demo purposes, I am taking the example from the site:
https://postimages.org/

it("Upload multiple file using selectFile", () => {
cy.visit("https://postimages.org/");
   cy.get("#uploadFile").selectFile(["cypress/fixtures/images/nature_evening.png","cypress/fixtures/images/nature_night.png"],{ action: "drag-drop" });
     cy.origin('https://postimg.cc/', () => {
     cy.get('.controls', { timeout: 20000 }).contains('Upload completed!');
     cy.get(".imagetitle").eq(0).should("have.text", "nature_evening");
     cy.get(".imagetitle").eq(1).should("have.text", "nature_night");
   });
 })

The test visits the PostImages website, selects two image files using the “selectFile” method, and then asserts that the files were uploaded successfully by checking for the presence of the file names in the UI.

The test also uses the “origin” command to ensure that the assertions are performed on the correct domain and sets a timeout of 20 seconds for the “controls” element to appear.

cy.get(“#uploadFile”).

cy.get(“.imagetitle”).

cy.get(‘.controls’)

Code Walkthrough

Step 1

It visits the “https://postimages.org/” website.

Step 2

It selects the file inputs with the ID “uploadFile”.

Step 3

Below command is used to navigate to a URL starting with “https://postimg.cc /” using the cy.origin() command.

Step 4

After uploading the image successfully, you can verify the message “File Uploaded!”

Output

In the output, you can see images are uploaded successfully, and the message “File Uploaded!” is verified.

Ace your Protractor interview with these 50+ Protractor interview questions. Boost you confidence and land your dream job with this comprehensive guide.

Using Cypress for file upload with the cypress-file-upload plugin

Another way to upload the file is using the plugin cypress-file-upload. It is a third-party plugin for the Cypress testing framework that allows you to simulate file uploads in your Cypress tests.

With cypress-file-upload, you can simulate file uploads using the attachFile() command, which can take various options such as file content, file name, and MIME type. This makes it easy to test different file types and sizes and to ensure that your file upload functionality is working as expected.

Some of the key features of the *cypress-file-uploa*d plugin include:

Support for multiple file selection and upload
Automatic handling of file input visibility and focus
Support for drag-and-drop file upload
Customizable upload options, such as file name and MIME type
Integration with other Cypress plugins and framework

Let’s first install the cypress-file-upload plugin.

Step 1

Run the below command:

npm install — save-dev cypress-file-upload

The package will be visible once the above command has been properly executed. The cypress-file-upload plugin has updated JSON.

Step 2

Update commands.js with the below line under cypress > support > commands.js.

import ‘cypress-file-upload’;

Demo — Uploading files using the cypress-file-upload plugin

Test Scenario

Visit the site: https://the-internet.herokuapp.com/upload.
Provide the path of the .png file you want to upload.
Then attach the file to the input element using the method attachFile().
After uploading, verify the title of the uploaded image.

Let’s take an example with the site https://the-internet.herokuapp.com/upload to upload the file using the plugin.

it('File Upload using cypress-file-upload npm package', () => {
     cy.visit('https://the-internet.herokuapp.com/upload')
       const filePath = 'images/nature_evening.png'
       cy.get('input[type="file"]').attachFile(filePath)
       cy.get('#file-submit').click()
       cy.get('#uploaded-files').contains('nature_evening.png')
   })

Code Walkthrough

This is a Cypress test that automates file upload functionality using the cypress-file-upload npm package. Here’s what the test does:

Step 1

Visit the upload page of the “the-internet.herokuapp.com” website.

Step 2

It defines a filePath variable that contains the path of the file to be uploaded.

Step 3

This command attaches the file to it using the attachFile() command provided by cypress-file-upload.

Step 4

It clicks on the “Upload” button using cy.get(‘#file-submit’).click().

Step 5

It verifies that the file has been uploaded successfully by checking if the file name is displayed on the page, using cy.get(‘#uploaded-files’).contains(‘nature_evening.png’).

Output

How to use Cypress for file download?

Cypress does not natively support file downloads. This means you cannot use Cypress commands to download a file from your web application.

You can use Cypress for file download using the below methods:

Using Cypress for file download with the readFile().
Using Cypress for file download with the cypress-downloadfile plugin.
Wait and verify for the file to be downloaded using cy-verify-downloads plugin.

Using Cypress for file download with the readFile()

We can use readFile() to verify the content in the file, which already downloads under the folder, e.g.,/cypress/downloads/.

Syntax

cy.readFile(‘cypress/downloads/uploadData.txt’)

Below is the example to read the downloaded file from the particular path.

it("Upload the file using .selectFile with select mode", () => {
   cy.readFile('cypress/downloads/uploadData.txt').should('contain', 'download file functionality in cypress')
 });

Code Walkthrough

Using the cy.readFile() command read the contents of a file called *uploadData.txt *located in the cypress/downloads directory.

Output (Pass Scenario)

When the string ‘download file functionality in cypress’ matches, the test case is passed.

Output (Fail Scenario)

When the expected string does not match, the test case fails. For example, do a minor tweak to the string ‘download file functionality in cypress test’.

it("Download the file in cypress", () => {
   cy.readFile('cypress/downloads/uploadData.txt').should('contain', 'download file functionality in cypress test')
 });

Using Cypress for file download using the cypress-downloadfile plugin

This plugin allows you to simulate file downloads in your Cypress tests and verify the downloaded files. Using the cypress-downloadfile plugin, you can automate and validate file download functionality in your Cypress tests, ensuring that the expected files are being downloaded correctly. It provides a convenient way to handle file downloads and perform necessary assertions and validations.

Let’s install the plugin cypress-downloadfile.

Step 1

Run the below command to download the plugin.

npm i — save-dev cypress-downloadfile

In package.json, we can see the package cypress-downloadfile is installed.

Step 2

Add the following code under the file cypress/support/commands.js.

require(‘cypress-downloadfile/lib/downloadFileCommand’)

Step 3

Add the following code under the file cypress.config.js.

const { defineConfig } = require("cypress");
const {downloadFile} = require('cypress-downloadfile/lib/addPlugin');


module.exports = defineConfig({
 e2e: {
   setupNodeEvents(on, config) {
     on('task', {downloadFile});
     // implement node event listeners here
   },
 },
});

Demo — Downloading files using the cypress-downloadfile plugin

Test Scenario

Download the file using the downloadFile() method: https://www.learningcontainer.com/wp-content/uploads/2020/04/sample-text-file.txt
After downloading, verify the text ‘Lorem ipsum dolor sit amet’ in the downloaded file.

Implementation

it('File Download using cypress-downloadfile npm package', () => {
     cy.downloadFile('https://www.learningcontainer.com/wp-content/uploads/2020/04/sample-text-file.txt',
         'cypress/fixtures/download_folder', 'data.txt')
     cy.readFile('cypress/fixtures/download_folder/data.txt').should('contain', 'Lorem ipsum dolor sit amet')   
 })

Here’s Top 30 Robot Framework Interview Questions and Answers that will help you boost your confidence in an Interview.

Code Walkthrough

Step 1

The cy.downloadFile is used to download a file from the URL https://www.learningcontainer.com/wp-content/uploads/2020/04/sample-text-file.txt. The file is saved to the directory cypress/fixtures/download_folder with the name data.txt.

Step 2

The cy.readFile is used to read the contents of the downloaded file at cypress/fixtures/download_folder/data.txt.

Step 3

Finally, the .*should() *assertion method in Cypress is used to verify that the contents of the file contain the string ‘Lorem ipsum dolor sit amet’.

Output

You can also use Cypress for file upload and download on a cloud-based testing platform. This helps you improve the reliability and robustness of your Cypress tests and ensure your web applications work correctly on a multitude of browsers and platforms. For this, you can leverage a digital experience testing platform like LambdaTest that offers a scalable Cypress cloud to perform Cypress UI automation across 50+ real browsers and operating systems.

Subscribe to the LambdaTest YouTube Channel to get the latest updates on tutorials around Selenium testing, Cypress e2e testing, Appium, and more.

You can even accelerate your software release cycles by performing Cypress parallel testing on multiple browsers and platforms simultaneously.

Note: Here is our support documentation to help you get started with Cypress testing.

Are you prepared to enhance your proficiency in Cypress automation? Enroll in our exclusive Cypress 101 certification program designed specifically for developers and testers aiming to broaden their expertise in Cypress test automation. Acquire advanced knowledge, refine your skills, and unlock a realm of new possibilities on your test automation path.

Conclusion

Downloading and uploading files are commonly used features in many applications. Automating these tasks using the Cypress automation tool can improve the reliability and robustness of your tests. By automating these features, you can simulate user interactions and validate the expected behavior of these functionalities.

By incorporating these automated tests into Cypress for file upload and download, you can catch potential issues and ensure that the download and upload functionalities of your application are working as intended. It provides an additional layer of confidence in the functionality and stability of your application.

Frequently Asked Questions (FAQs)

How to upload an xlsx file in Cypress?

To upload an XLSX file using Cypress, you can follow these steps:

Prepare the XLSX file
Write the Test Script
Run the Test

Ensure that the XLSX file is placed in the cypress/fixtures folder or adjust the path accordingly in the test script. Also, note that the mimeType provided in the attachFile command corresponds to the XLSX file format.

That’s it! You can now upload XLSX files using Cypress and perform necessary assertions or validations as needed.

How To Use Cypress Intercept For Handling Network Requests

Kailash Pathak — Thu, 09 Mar 2023 09:34:53 +0000

Before intercepting network requests, one of the main challenges was that it was difficult to debug and diagnose network-related issues. Developers needed more visibility into what was happening with network traffic between a client and a server.

Intercepting network requests provides insight into the network traffic generated by the application. Without this capability, troubleshooting issues can become more complex and time-consuming. The team may not have the necessary information to identify the cause of the problem, which can result in delays in the testing process.

Moreover, QA teams had little access to the requests and responses transmitted between the client and server due to their inability to intercept and examine network data. Because of this, it was challenging to comprehend the application’s behavior.

Many tools can be used for intercepting network requests. Cypress is one of the most popular automation testing frameworks through which you can intercept network requests. Cypress intercept — cy.intercept() is a method provided by Cypress that allows you to intercept and modify network requests made by your application. It will enable you to simulate different server responses or network conditions to test how your application handles them. This can be very useful when writing end-to-end tests. This can be very useful when writing end-to-end tests.

To use the Cypress intercept — cy.intercept() method, you can call it within a Cypress test like this:

cy.intercept(<url>, <options>)

The parameter specifies the URL of the network request you want to intercept, and is an object that can be used to specify additional options, such as the response to return and the status code to use, and so on.

Before deep diving into using Cypress intercept for handling network requests, let’s first understand the nuances of network testing while performing Cypress testing.

Test your native, hybrid, and web apps across all legacy and latest mobile operating systems on the most powerful online emulator Android.

What are Network Requests?

Network requests refer to exchanging data between a client and a server over a network. When testing web applications, verifying the correct metadata, such as headers, cookies, authentication tokens, and other information sent with the request, can be important.

In testing, network request metadata can be used to verify that the correct headers and cookies are being sent with the request, to ensure that the data is being sent in the correct format, and to verify that the authentication tokens are being set correctly. Tools such as Cypress provide APIs for intercepting and inspecting network request metadata, making it easy to test the behavior of network requests and ensure that they are being handled correctly.

Network requests can be made using HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure) protocols. HTTP is the traditional protocol for sending and receiving data over the Internet. It’s a simple, text-based protocol for sending and receiving information between clients and servers.

HTTPS is a secure version of the HTTP protocol that uses SSL/TLS encryption to secure the data transmitted between the client and the server. HTTPS protects sensitive data, such as passwords, credit card information, and other personal information. When you make an HTTPS request, your browser establishes an encrypted connection with the server. All data exchanged between the two parties is encrypted to ensure that third parties cannot intercept and read it.

This is crucial to how the Internet works and allows data transfer between devices.

Here’s an example:

A user opens a web browser and types in the URL for a website, such as “www.example.com”.
The browser sends a network request to the server hosting the website, asking for the HTML, CSS, and JavaScript files that make up the website.
The server receives the request and sends back the requested files.
The browser receives the files and uses them to render the website on the user’s screen.
The user interacts with the website by clicking a button or filling out a form.
The browser sends another network request to the server with additional data, such as the information the user entered in the form.
The server processes the request and returns the appropriate response, such as confirming the form submission or sending back data for the next page of the website.

In the below diagram, you can see there is a network request between a client (the web browser) and a server (the website host). The client requests resources and the server sends back the requested information. The process can be repeated as the user interacts with the website.

Assess the performance of your native, hybrid, and web apps on the most potent online Android emulator, covering both current and older mobile operating systems.

What is Intercepting Network Requests?

Intercepting network requests refers to intercepting and inspecting the traffic between a client and a server during communication over a network. Web development usually involves intercepting HTTP requests and responses.

Intercepting network requests can be helpful in various situations:

Debugging and troubleshooting network issues.
Inspect the request and response payloads.
Modify the requests in real time.
By intercepting and modifying network requests, inspecting and manipulating various aspects of the communication, such as headers, parameters, cookies, and response data, is possible.

When intercepting network requests, usually have a proxy between the client and the server. The proxy will intercept all network traffic between the two endpoints and allow the user or tool to inspect and modify the traffic before forwarding it to its intended destination.

In the diagram above, the client is requesting the server, but the request is intercepted by a proxy before it reaches the server. The proxy can then analyze and modify the request before forwarding it to the server and can also analyze and modify the response before sending it back to the client.

One commonly used tool for analyzing network traffic is Wireshark. Wireshark is a free and open-source packet analyzer that lets you capture and analyze network traffic in real time.

Another tool for analyzing network traffic is tcpdump. It can capture and filter network traffic for various protocols, including TCP, UDP, ICMP, and more.

Experience seamless testing of your native, hybrid, and web apps across an array of current and older mobile operating systems on the highly robust Android online emulator.

Why Intercept Network Requests?

Intercepting network requests can provide many benefits, depending on the context and the reason for the interception. Here are a few examples:

Debugging

By intercepting network requests, developers can easily see what data is being sent and received during different application stages. This can help to quickly identify and resolve any issues related to the application’s network communication.

Testing

Intercepting network requests can be beneficial for automating tests of web applications. Test scripts can be written to simulate user actions and inspect the resulting network traffic, allowing developers to automate the testing of complex workflows and scenarios.

Data Modification

Interception can modify network requests, allowing developers to manipulate the data sent over the network.

Accelerating test execution

By intercepting network requests and returning mock responses, you can reduce the number of requests your application makes to the server.

Security:

Intercepting network requests can also be used as a security measure. For example, In organizations, you can monitor network traffic to detect malicious activity, such as a cyber-attack.

Modifying network requests:

By intercepting network requests, developers can modify the requests made by an application to test different scenarios or to implement new features. LT Debug by LambdaTest is a useful tool for modifying network requests during testing and debugging. By modifying requests and analyzing responses, you can quickly identify and fix issues in your code.

You can learn more about it through this LT Debug tutorial.

Below are some other benefits of intercepting the network request, which are helpful for the network team.

Traffic analysis: By capturing and analyzing network requests, network administrators can gain insights into network usage patterns, identify potential performance bottlenecks, and optimize the network for better performance.
Content filtering: By intercepting network requests, organizations can filter content based on various criteria, such as security policies, bandwidth limitations, or content type.
Monitoring: Interception can also be used for monitoring purposes, for example, to gather statistics about the usage of an application or to gain insights into user behavior.

Are you using Playwright for automation testing? Run your Playwright test scripts instantly on 50+ browser/OS combinations using the LambdaTest cloud.

QA Tools for Intercepting Network Requests

Here are some QA automation testing tools that can be used for intercepting network requests

Cypress: Cypress can intercept network requests and manipulate their responses. In Cypress, you can intercept network requests using the Cypress intercept — cy. intercept() method. This command allows you to intercept and modify network requests and responses.
Playwright: With Playwright, you can intercept network requests using the page.route() method. This method allows you to intercept network requests and provide a custom response.
Postman: Postman is a popular API development and testing tool that allows you to inspect and modify network requests. It has a user-friendly interface and a wide range of features, making it a great option for QA automation testing.
Charles: Charles is a web debugging proxy tool that can inspect, debug, and modify network requests. It is widely used by developers to troubleshoot issues with web applications and APIs.
Fiddler: Fiddler is a web debugging proxy tool that allows you to inspect and modify network requests, and it is widely used for QA automation testing.
JMeter: JMeter is a popular open-source load testing tool with features for intercepting and modifying network requests. JMeter can be used to test the performance of web applications and APIs.
Burp Suite: Burp Suite is a powerful and widely used tool for testing web applications. It allows you to intercept and manipulate HTTP requests and responses and provides detailed information about the requests & responses.
SoapUI: SoapUI is an open-source tool for testing web services, including features for intercepting network requests. It is widely used for testing SOAP and REST APIs.
Selenium: Selenium is a popular open-source framework for automating web application testing. While Selenium itself does not have built-in capabilities for intercepting network requests.

In addition to the above tools, popular cloud testing platforms like LambdaTest provide integration with such QA tools, including Cypress, Selenium, and Playwright. With LambdaTest, you can perform Cypress automation at scale over an online browser farm of 3000+ browsers and operating systems. Furthermore, you can perform Cypress parallel testing and cut down your test execution time by multiple folds.

A comprehensive end to end Testing tutorial that covers what E2E Testing is, its importance, benefits, and how to perform it with real-time examples.

Intercepting Network Requests with Cypress

Here are some common use cases for using Cypress intercept for handling network requests.

Mocking APIs

Cypress allows developers to create mock APIs to simulate different server responses. This is useful when testing application behavior under different conditions, such as when the server is down, or the response is delayed.

Testing HTTP requests and responses

By intercepting network requests, the Cypress UI automation tool allows developers to test how the application handles HTTP requests and responses. This includes testing error response handling, response time, and response code.

Testing authorization and authentication

Using Cypress, developers can test how their application handles authentication and authorization by intercepting network requests and passing the authorization tokens.

Here are some circumstances under which authorization and authentication are used in intercepting network requests:

Access Control: Authorization is used to control access to resources such as files, web pages, APIs, and databases. By requiring authorization, only authorized users or systems are granted access to the resource.
Secure Data Transmission: Authentication ensures data is securely transmitted between systems. By authenticating the sender and receiver, data can be encrypted and decrypted only by the intended parties.
Testing for performance-related issues

Cypress UI testing tool can be used to measure the performance of web applications by intercepting network requests and measuring the response times of each request. This can help developers identify performance bottlenecks in their applications and optimize performance.

Using Cypress Intercepts for Handling Network Requests

Cypress is a JavaScript-based end-to-end testing framework that makes writing, running, and debugging tests for web applications easy. It has built-in support for intercepting and stubbing network requests, allowing you to control the data returned from the server and make assertions about the network requests made by your application while performing Cypress end to end testing.

You can use the Cypress intercept — cy.intercept() command to intercept network requests in Cypress. This Cypress intercept command takes a URL pattern and a callback function as arguments and will intercept all requests that match the pattern. In the callback function, you can then modify the request, return a response, or continue the request to the network.

Below are the methods you can use in Cypress for Spy and stub network requests and responses.

cy.intercept(url)
cy.intercept(method, url)
cy.intercept(routeMatcher)

Here’s a simple example of how you could use the Cypress intercept command to return a fake response for a certain request:

cy.intercept('/api/data', {
 method: 'GET'
}).as('getData')
 .reply(200, {
   data: 'Test Data'
 });


// ... Perform your test logic ...
cy.wait('@getData')
 .its('response.body')
 .should('deep.equal', {
   data: 'Test Data'
 });

In this example, the Cypress intercept — cy.intercept() command is used to intercept all GET requests to the /api/data endpoint. The .reply method is then used to return a fake response with a status code of 200 and a JSON body of { data: Test Data’ }.

The cy.wait() command is then used to wait for the request to be intercepted and complete, and the response body is asserted to match the expected value.

Before explaining all the methods in detail, let’s first see how the Cypress intercept — cy.intercept() method works.

How does the cy.intercept() method work?

The Cypress intercept or cy.intercept() is a method used to intercept and modify HTTP requests and responses made by the application during testing. This allows you to simulate different network scenarios and test the behavior of your application under different conditions.

In the diagram below, the Cypress intercept — cy.intercept() method intercepts the requests and responses made by the Application Under Test (AUT). The Cypress intercept method can intercept requests to specific URLs or requests made by specific methods (e.g., GET, POST, etc.)

The steps of the diagram are explained below:

The client (browser) initiates a request to the server.
The server receives the request and sends back a response.
The client receives the response and handles it.
Cypress test code intercepts the request before it reaches the server.
The test code can modify the request or the response in any way it wants, such as adding headers, delaying the response, or changing the status code.
The test code returns a stubbed response that replaces the actual response from the server.
The client receives the stubbed response and handles it as if it came from the server.

Once you get the response, we can verify the stubbed response by explaining the assertion below with various examples.

Different ways of Intercepting Network Requests in Cypress

There are various ways to use Cypress intercept for handling network requests:

Matching URL

First way of intercepting the request is by Matching the URL. There are three ways of matching the URL.

Interception by matching the exact URL.

it('Intercept by Url', () => {
cy.visit('https://reqres.in/');
cy.intercept('https://reqres.in/api/users/').as('posts')
cy.get("[data-id=users]").click()
cy.wait('@posts').its('response.body.data').should('have.length', 6)
})

In this example, we are intercepting the complete https ://reqres.in/api/users/ URL. The intercepted request is assigned a named alias ‘posts’ using the .as method. The test then waits for the ‘posts’ request to complete and verifies the length of the response body.

Interception of multiple URLs using pattern matching.

it('Intercept by use pattern-matching to match URLs', () => {
cy.visit('https://reqres.in/');
cy.intercept('/api/users/').as('posts')
cy.get("[data-id=users]").click()
cy.wait('@posts').its('response.body.data').should('have.length', 6)
})

In this example, we are intercepting the request having the URL matches the /api/users/ pattern. The intercepted request is assigned a named alias ‘posts’ using the .as method.

The test then waits for the ‘posts’ request to complete and verifies the length of the response body.

Interception of the URL using a regex pattern.

it('Intercept by regular expression', () => {
cy.visit('https://reqres.in/');
cy.intercept('/\/api/users?page=2').as('posts')
cy.get("[data-id=users]").click()
cy.wait('@posts').its('response.body.data').should('have.length', 6)
})

In this example, the Cypress intercept — cy.intercept() method intercepts the URL that matches the regex pattern /\/api\/users. The as() method gives a name to the intercepted request, which can be later used with cy.wait() to wait for the response. In this case, cy.wait(‘@posts’) waits for the intercepted request to complete before proceeding with the test.

Matching method

Another way of intercepting the request is by Matching the methods. By default, if you don’t pass a method argument, then all HTTP methods (GET, POST, PUT, PATCH, DELETE, etc.) will match. By passing the method in the cy.intercept() it will intercept a particular method request in a network call.

Suppose you have provided an interceptor command like cy.intercept('/api/users/'). In that case, we will match parameters in all Methods (GET, POST, PUT, PATCH, DELETE, etc.)

But if you pass the Method name in command cy.intercept ('GET', '/users?page=2'), then in that case, only the GET method is intercepted.

it('Intercept by matching GET method', () => {
   cy.visit('https://reqres.in/');
   cy.intercept('GET','api/users?page=2').as('posts')
   cy.get("[data-id=users]").click()
   cy.wait('@posts').its('response.body.data').should('have.length', 6)
 })

Another example of POST request where we have manipulated the response with providing the data in the body. In the below example, we have provided the data in the body, and thus, we have mocked the data with provided data in the body.

it('Intercept by matching POST method', () => {
   cy.visit('https://reqres.in/');
   cy.intercept('POST', 'api/users', (req) => {
     req.reply({
       status: 200,
       body: {
         "name": "John",
         "job": "QA Manager",
     }
     })
   }).as('updateuser')
   cy.get("[data-id=post]").click()
   cy.wait('@updateuser')
 })

Below is the output of the above test case. You can see we have mocked the data by intercepting the POST call.

Matching with RouteMatcher

RouteMatcher is a part of the Cypress API that allows you to match specific network requests based on their URL, method, headers, and other attributes.

By using a RouteMatcher, you can match requests based on their URL patterns, which provides a flexible way to intercept API requests and test our application’s behavior under different conditions.

it('Intercept by RouteMatcher ', () => {
   cy.visit('https://reqres.in/')
   cy.intercept({
     method: 'GET',
     url: 'https://reqres.in/api/users/**'
   }, (req) => {
     req.reply({
       statusCode: 200,
       body: {
         data: [{
           id: 7,
           email: 'tim.Bluth@reqres.in',
           first_name: 'tim',
           last_name: 'Bluth',
           avatar: 'https://reqres.in/img/faces/1-image.jpg'}, {
             id: 8,
             email: 'janet.weaver@reqres.in',
             first_name: 'Janet',
             last_name: 'Weaver',
             avatar: 'https://reqres.in/img/faces/2-image.jpg'
           }
         ]
       }
     })
   }).as('postdata')
   cy.wait('@postdata').its('response.body.data').should('have.length', 2)
 })

In this example, we have used a RouteMatcher to match any GET request to the https://reqres.in/api/users/** endpoint. The ** notation matches any path after /api/users/. We then use the req.reply() function to return a custom response for matching requests. Finally, we load our application and verify that the response has length 2.

Output:

The output of the above test case is attached below:

Pattern Matching

In Pattern matching, you can provide the matching pattern string like in the below example any GET Or PATCH requests that match the pattern /users/ will be intercepted.

it('Intercept by Pattern Matching using glob matching ', () => {
   cy.visit('https://reqres.in/')
   cy.intercept({
     method: '+(GET|PATCH)',
     url: '**/users/**'
   }, (req) => {
     req.reply({
       statusCode: 200,
       body: {
         data: [{
           id: 7,
           email: 'kim.smith@reqres.in',
           first_name: 'Kim',
           last_name: 'Smith',
           avatar: 'https://reqres.in/img/faces/1-image.jpg'}, {
             id: 8,
             email: 'janet.weaver@reqres.in',
             first_name: 'Janet',
             last_name: 'Weaver',
             avatar: 'https://reqres.in/img/faces/2-image.jpg'
           }
         ]
       }
     })
   }).as('postdata')
   cy.wait('@postdata').its('response.body.data').should('have.length', 2)
 })

Output:

In the below code you can see the data that we have mock displaying under response body

Stubbing a response

In Cypress, stubbing a response refers to the process of intercepting a network request made by the application being tested and returning a predefined response instead of the actual response from the server.

There are two ways to stub a response for a network request:

With a string

Here’s an example of how you can use the Cypress intercept — cy.intercept() method to stub a response for a network request by passing a string in the body.

it('Stubbing a response With a string', () => {
   cy.visit('https://reqres.in/')
   cy.intercept('GET', '**/users/**', {
     statusCode: 200,
     body: 'Hello, world!'
   }).as('getUsers')
   cy.wait('@getUsers')
   cy.get('@getUsers').then((interception) => {
     expect(interception.response.body).to.equal('Hello, world!')
})
 })

Output:

2. With Fixture files

Another way of stubbing the response using the fixture file. You can mock the data from the fixture file instead of providing data in the body.

it('Stubbing a response With Fixture file', () => {
   cy.visit('https://reqres.in/')
   cy.intercept('GET', 'https://reqres.in/api/users?page=2', { fixture: 'users.json' }).as('getUsers')
cy.visit('https://reqres.in/')
cy.wait('@getUsers')
cy.get('.data').should('have.length', 6)
 })

In this example, we are intercepting a GET request to the endpoint https: //reqres.in/api/users?page=2, and responding with a fixture file called users.json. We also use the .as() method to assign the intercepted request to an alias to wait for the response before performing further actions.

Assuming you have a fixture file named users.json in your cypress/fixtures directory, this test will verify that the .data element on the page has a length of 6, which matches the number of records in the users.json fixture file.

Output:

In the below output of the above code, you can see the data we have mocked using the fixture file.

Changing Headers

You can also use the Cypress intercept — cy. intercept() method to mock header data.

it('Intercept a request and modify headers', () => {
   cy.visit('https://reqres.in');
   cy.intercept('GET', 'https://reqres.in/api/users', (req) => {
     req.headers['Authorization'] = 'Bearer my-token';
   }).as('getUserList');
   //cy.visit('https://reqres.in/api/users');
   cy.wait('@getUserList')
   cy.get('@getUserList').then((interception) => {
     const requestHeaders = interception.request.headers;
     expect(requestHeaders).to.have.property('Authorization', 'Bearer my-token');
   });
 });

In this example, we intercept a GET request to https: //reqres.in/api/users and modify the Authorization header by adding a token value. We give this interception a unique alias using the .as() command so that we can wait for it to complete using cy.wait().

After waiting for the interception to complete, we use the cy.get(‘@ getUserList’) command to get the interception object and assert that the Authorization header was modified correctly.

How to Override an existing Cypress intercept?

Overriding an existing Cypress intercept allows you to modify or cancel an existing network request intercept that has already been defined in your test code. This can be useful when you want to change the behavior of an existing intercept, for example, to simulate a different response from a server or to modify the request data in a different way.

The main difference between intercepting network requests and overriding an existing intercept is that intercepting allows you to define new intercepts in your test code, while overriding allows you to modify existing intercepts. Cypress provides a rich API for working with both intercepts and overrides to help you thoroughly test and debug your web applications.

The below example shows how you can use the Cypress intercept — cy.intercept() method to override an existing intercept and modify the behavior of your application during testing.

describe.only('Override an existing intercept example', () => {
 beforeEach(() => {
   cy.intercept('GET', 'https://reqres.in/api/users').as('getUsers')
 })


 it('overrides the response of the /api/users request', () => {
   cy.visit('https://reqres.in/')
   cy.intercept('GET', 'https://reqres.in/api/users', (req) => {
     req.reply((res) => {
       res.send({
         data: [{ id: 1, email: 'test@test.com' }],
         page: 1,
         per_page: 1,
         total: 1,
         total_pages: 1
       })
     })
   }).as('getUsers')


   cy.wait('@getUsers').then((interception) => {
     expect(interception.response.body.data).to.have.length(1)
     expect(interception.response.body.data[0].email).to.eq('test@test.com')
   })
 })
})

In this example, we first define an intercept for the GET /api/users request and give it an alias of getUsers. Then, in the test itself, we override the same request by defining a new intercept with the same alias of getUsers.

In the new intercept, we use the req.reply() function to override the original request’s response and return a new response that includes a single user with an email of ‘test@ test. com‘. Finally, we use the cy.wait() command to wait for the getUsers alias to complete, and then we test the response to ensure it contains the expected data.

Output:

Looking to take your Cypress automation skills to the next level? This Cypress 101 certification course is designed for developers and testers who already understand Cypress and want to advance their knowledge and skills around Cypress test automation.

In this Appium tutorial, learn about Appium and its benefits for mobile automation testing. Take a look at how Appium works and see how to perform Appium testing of your mobile applications.

Wrapping up

Using stubbing, requests to a network are intercepted and replaced with predefined responses, rather than sending the request over the network and waiting for a response.

However, stubbing can also lead to false positives, as the behavior of the stubbed requests may not accurately reflect the behavior of the actual requests. This can lead to a false sense of security in your tests and may miss bugs or errors that only occur in the actual network request.

On the other hand, not using stubbing with the Cypress intercept — cy .intercept() can provide a more accurate picture of the behavior of your application in the real world. By allowing actual network requests to be made and handling them accordingly, you can be more confident that your tests accurately reflect the behavior of your application in the wild.

Frequently Asked Questions (FAQs)

1. What does intercept do in Cypress?

In Cypress, intercept is a method used to intercept and modify network requests the application makes under test. When intercepting a network request, Cypress can manipulate its request/response headers and body or even simulate network failures. This is useful for testing scenarios involving network requests, such as testing authentication or how the application handles different responses.

2. What is the difference between Cypress intercept and request?

Cypress is a JavaScript end-to-end testing framework that allows you to write and run automated tests for web applications.

cy.intercept() intercepts and modifies HTTP requests and responses made by your application. It allows you to mock or stub server responses, modify the request headers, and perform assertions on the intercepted requests and responses.

cy.request(), on the other hand, sends an HTTP request to the specified URL and returns the server’s response. It allows you to simulate HTTP requests and verify the server response in your tests.

Playwright vs Selenium vs Cypress: A Detailed Comparison

Kailash Pathak — Thu, 19 Jan 2023 00:14:45 +0000

With multiple testing frameworks available, choosing which is best for your product becomes more challenging. While various testing tools are available in the market, Selenium has been a well-established player for quite some time. However, newer automation testing frameworks such as Cypress and Playwright have recently provided Selenium with serious competition. I have used Selenium and Cypress, and recently started using Playwright.

Every tool/framework has its pros and cons. When I switched from Selenium to Cypress, I found that Cypress was speedy and less flaky compared to Selenium. I saw test cases that had previously taken a long time and resulted in a failure, now executed well in the local environment and the CI/CD pipeline.

Playwright, comparatively a newer entrant in the market, is an open-source framework primarily used for end to end testing. Built by Microsoft, it supports prominent languages like Python, Java, JavaScript, C#, and more. It comprises features and capabilities more aligned with the modern web.

When a new user plans to develop a framework from scratch, choosing the right tool or framework can sometimes be tricky as they are trying to figure out which framework will work best for their project. As I started my career in automation, I used Java, which allowed me to leverage the benefits of the Selenium framework to automate web application testing.

Nevertheless, I am also facing many challenges with my current project at the moment. To solve these difficulties, I am forced to look into other tools to assist me.

Given that there are several considerations to take into account, including in-house technical expertise, ease of use, and CI/CD integration, it is important to determine which framework or tool would be the most suitable option based on these factors and others that are important in selecting the optimal solution. Needless to mention that the framework must let you run tests in a CI/CD pipeline.

The Cypress framework has been my go-to tool for the last three or four years. It offers many features (Automatic Waiting, Flake Detection, Network Traffic Control, Screenshots and Videos, Debuggability, etc.).

However, several alternatives to Selenium and Cypress are currently challenging them (one of which is Playwright, which offers a variety of functionalities).

In this Playwright vs Selenium vs Cypress blog, you will learn more about each tool/framework, and I’ll also compare Playwright, Selenium, and Cypress. The learnings of this Playwright vs Selenium vs Cypress blog will help you choose the ideal tool for your project.

Below are the npm trends of Playwright vs Selenium vs Cypress.

**Note: **I have used tools and frameworks interchangeably throughout this blog on Playwright vs Selenium vs Cypress.

What is Playwright?

Playwright is an open-source automation framework for end-to-end testing. It supports most modern rendering browsers, including Firefox, Chromium, and Webkit. Playwright is created and maintained by Microsoft and has steadily been gaining in popularity.

It is a Node library that automates the Chromium, WebKit, and Firefox browsers using a single API. It enables quick, efficient, competent, and reliable cross-browser c.

Playwright test framework supports Jest, Mocha, Jasmine, and other prominent CI servers using a single API. Playwright offers cross-language support, which includes TypeScript, JavaScript, Python, .NET, and Java.

Here are some of the prominent features of Playwright automation framework:

One API for any browser/platform: Playwright supports all modern rendering engines, including Chromium, Firefox, and WebKit. It supports Windows, Linux, and macOS and additionally supports native mobile emulation of Google Chrome for Android and Mobile Safari.
Reduced flakiness: Playwright waits for actionable elements before performing actions. To reduce flakiness, features like test retries, execution trace capture, videos, and screenshots are also available.
Test Case Execution in Isolation: Every test that Playwright runs has a unique browser context. The same thing as a new browser profile is browser context. With no additional overhead, this gives complete test isolation.
Powerful Tooling: Playwright comes bundled with tools like Codegen, Playwright inspector, and Trace Viewer:
Codegen: Using Codegen, you can record the test cases and save them in any language (JavaScript, Python, .NET, Java, TypeScript). Recording the test cases is helpful for the beginner from a learning perspective. But if you want to use the recorded script in a live project, it’s not a good approach from a maintainability perspective.
Playwright inspector: Using Playwright inspector, you can inspect the page, see click points, and explore execution logs.
Trace Viewer: Capture all the information that helps investigate the test failure.

As per the Playwright GitHub repository, Playwright continues to attain popularity with:

Stars: 46.4k
Forks: 2.3k
Used By: 20.5k
Releases: 91
Contributors: 345

Playwright Architecture

Playwright works directly with the WebSocket, which means once you trigger the test, the code will be converted into JSON format and will be sent to the server using Web socket protocol. Once the connection or handshake connection is established, commands are sent between your test and the Playwright server.

Client and server connections will remain active until one or both parties discontinue them. After closing the connection, the connection is terminated from both ends. One of the reasons that Playwright is fast is because the connection stays active as long as neither party terminates it.

To learn more about Playwright automation testing, you can refer to this blog on the Playwright framework.

In the next section of this blog on Playwright vs Selenium vs Cypress, we will learn about the Selenium test automation framework.

What is Selenium?

Selenium is an open-source framework for automated testing that is used to verify web applications across many platforms and browsers. Using Selenium, you can automate your application with major browsers in different programming languages such as Java, JavaScript, C#, Ruby, PHP, and Python.

Using the Selenium framework, testers can use a grid of browser instances to run test cases in parallel, which can help to speed up the testing process. By running test cases in parallel, you can complete the testing phase of your CI/CD pipeline more quickly, which can help to accelerate the overall development process.

We’re not going to do a long explanation of Selenium’s tool suite here. Instead, I will give you a brief overview of the Selenium suite:

Selenium WebDriver

Selenium WebDriver is a library whose APIs are called from the code, post which the commands are run on the browser of your choice. Using Selenium locators, elements can be identified and located, which is used to generate test cases. Then, using the WebDriver APIs, you may take action on those items and interact with them.

The script you create interacts directly with the browser, which is one of the reasons it runs significantly faster than Selenium RC, which has been deprecated. There are different drivers for different browsers, which ‘interpret’ the script you write for it.

Selenium IDE

Selenium IDE allows the user to record and edit the test steps and then play those steps. IDE (Integrated Development Environment) is a Firefox, Chrome, and Edge add-on used to build and run test cases. It is a simple tool that allows you to quickly create and execute automated tests without the need to write any code.

With Selenium IDE, you can record your actions in the browser, such as clicking on elements and filling out forms and then play them back to test the functionality of your web application. Selenium IDE also allows you to edit your scripts, add assertions to verify the behavior of your application, and export your scripts to other formats, such as HTML, Java, Python, and C#.

Selenium Grid

Selenium Grid is a tool that allows you to run your tests on different machines against different browsers in parallel. It allows you to run your tests on different machines, operating systems, and browsers. This can be particularly useful if you have a large test suite and want to run your tests as quickly as possible. It’s an environment where we have one ‘master’ system (the hub) which controls the child systems (the nodes).

With Selenium Grid, you can set up a hub, which is a central point that manages the test execution on the connected nodes. You can then connect any number of nodes to the hub, and these nodes can be used to execute tests in parallel. Each node represents a combination of operating systems, browsers, and versions, and you can specify which tests should be run on which nodes.

For example, you might set up a hub with three nodes: one running Chrome on Windows, one running Firefox on macOS, and one running Safari on iOS. You can then use Selenium Grid to run your tests concurrently on all three nodes, allowing you to test your application on all three platforms and browsers simultaneously.

How Selenium Grid Works:

You set up a hub, a central point of communication for the nodes that will execute your tests.
You set up one or more nodes, the machines that will run the tests. Each node can run tests on a different browser or operating system.
You configure the nodes to connect to the hub.
You write tests and use a client library, such as the Selenium WebDriver, to send commands to the hub. The hub will forward the commands to the appropriate node, executing the tests and sending the results back to the hub.

Using Selenium Grid can significantly speed up your test execution time, allowing you to run tests in parallel on multiple machines and browsers.

Selenium Trends on GitHub:

As per the Selenium GitHub repository, Selenium persists in acquiring popularity with:

Stars: 25.5k stars
Forks: 7.3k forks
Watching: 1.3k watching
Used By:175k
Contributors: 673

Selenium Architecture

Selenium is an open-source testing framework used for web automation testing. The JSON Wire Protocol was removed in Selenium 4 in favor of the W3C WebDriver Protocol, which is now the official standard for controlling web browsers. Nevertheless, the Selenium team continues to support the outdated protocol, which may be done via Selenium-supported language Bindings and Selenium Server.

The new protocol is called “WebDriver W3C”. It has acquired the acceptance of the “World Wide Web Consortium” (W3C). In Selenium 4 architecture, we can see direct communication between the client and server without needing the JSON Wire Protocol. The same protocol is used by Selenium WebDriver and web browsers, making test case execution quick and flakiness extremely low.

There are several benefits of using WebDriver W3C Protocol. WebDriver W3C Protocol is richer in comparison to the one JSON Wire Protocol. The Actions API is revamped to work with the WebDriver Spec. Action APIs would now let you perform multi-touch actions, zoom-in, zoom-out, pressing two keys simultaneously, and more.

For example, the Pinch-zoom sequence in W3C Protocol is represented by an action sequence consisting of three ticks and two-pointer devices of type-touch.

In the next section of this blog on Playwright vs Selenium vs Cypress, we will learn about the Cypress test automation framework.

What is Cypress?

Cypress is a front-end testing tool built for the modern web. It supports JavaScript and is used for end-to-end testing with the Mocha test framework. Mocha is a feature-rich JavaScript-based testing framework that simplifies asynchronous testing. Cypress is a powerful automation tool gaining popularity and becoming a viable alternative to Selenium.

In Cypress, you don’t need to install multiple dependencies; most required things for writing the test cases come as a bundle in Cypress. Cypress runs a test suite inside the browser, making it very fast compared to frameworks like Selenium. In the Cypress bundle, we have an in-built Chai assertion library that supports the Mocha framework, which provides the syntax for implementing test cases in Behavior-Driven Development (BDD) style.

Cypress automation tool addresses the following key pain points developers and QA engineers face when testing modern applications.

Easy installation: You can install Cypress with npm or their desktop application. Moreover, you do not need to install additional libraries, dependencies, drivers, nor need to install additional libraries, dependencies drivers.
Real-time reloads: In Cypress, you do not need to reload the test case. When you make changes to your test case, it is smart enough to trigger and run the test automatically.
Write Test case faster: Cypress is faster; within minutes, you can start writing the test case. Cypress runs tests within the browser that give us results almost identical to what users will experience.
Automatic waiting: In Cypress UI automation, you don’t need to add wait times or sleep to your tests. Cypress automatically waits for commands and assertions before moving on to the next step.
Screenshots and videos: Video of the entire suite is automatically captured. You can also capture Screenshots automatically of failure when running headlessly. This is extremely useful when tests fail.
Instructive Dashboard: Using Cypress cloud, we can run your test cases in CI/CD providers and record test results.

Cypress Trends on GitHub:

As per the Cypress GitHub repository, Cypress persists in acquiring popularity with:

Stars: 42.3k
Forks: 2.7k
Used By: 660k
Releases: 293
Contributors: 413

Check this out: Base64 Decode — Base64 decoding is a way of translating text form into binary data so that it can be transmitted more easily via e-mail and HTML form data.

Cypress Architecture

Cypress is a testing framework that is used to automate web applications. It has a unique architecture designed to make testing faster and more reliable. In Cypress UI testing, all commands are executed inside the browser without any driver binaries dependency. In the below screenshot, you can see tests are run inside the browser, so test execution is faster without any network lags.

There is a Node server behind Cypress, and the Node process constantly communicates, synchronizes, and performs jobs on behalf of each other. The Node server and browser communicate through WebSocket, which starts once the proxy is created.

Since tests are running inside the browser, it’s very easy to work directly on:

DOM
Local storage
Network layer
Window object

As the things mentioned above are very simple to access in Cypress, this is a significant advantage when running tests on Cypress in comparison to other test automation frameworks.

To learn more about Cypress testing, you can refer to this blog on Cypress test automation.

Check this out: This Prettify JSON online tool is completely free to use.

Comparing Playwright vs Selenium vs Cypress Features

Below are a few points for comparing Playwright vs Selenium vs Cypress.

Installation & Configuration

In this section, we will take a look at how to install and configure each of these tools, and what benefits they offer in terms of installation and setup.

Playwright:

When comparing Playwright vs Selenium vs Cypress installation and configuration, Playwright is easy to install and set up. There are different ways to install Playwright, some of which are explained below:

Here are some basic prerequisites for Playwright:

Ensure you have NodeJS installed.
Install a code editor. I will be using Visual Studio Code.

There are two ways of installing the Playwright:

Using the VS Code extension.
Using the init command.

Using the VS Code extension

Create a folder, e.g., Install_playwright.
Open the folder in VS Code.
Search Playwright extension in VS Code and install it.

Now Press command+shift+P (in Mac) and finally click on the OK button.

As we click on the OK button, the Playwright installation will start.

Using the init command

Create a folder, e.g., playwright_new_script.
Open the folder in VS Code.
Run from the project’s root directory npm init playwright@latest.
As we run the above commands, Playwright starts installing. (At the time of writing this blog, the latest version of Playwright is 1.29 ).

In the below screenshot, you can see we have two options. You can select either TypeScript or JavaScript.

We can see the default .spec file after successful installation.

To know more about how to set up and run the test cases in Playwright, you can follow this blog on end to end testing with Playwright.

Selenium:

To set up Selenium, we usually need to follow the steps below. This applies to the local Selenium Grid. The below steps are also applicable to Python and other Selenium-supported languages. Installation of Selenium Grid and Server is not applicable for cloud Selenium Grids like LambdaTest.

Install Java. Here’s the link to download and install JDK.

Install IDE. You can learn more about it through this blog on configuring Eclipse and IntelliJ.

Download Selenium WebDriver and Java Client Driver to be set up in Eclipse.
Create a TestNG project and run the Selenium test script. You can learn more about it through this blog on creating TestNG project in Eclipse.

Cypress:

In Cypress, installation is super easy. The good thing about Cypress is it has a folder structure. Just follow the folder structure and start developing the test cases. Using a predefined folder structure, you can develop the framework for your project.

To set up Cypress, follow the steps below:

Pre-requisites: Node should already be installed.
Generate package.json using the command npm init.
**npm install cypress –save-dev **command installs the latest version of Cypress. At the time of writing this blog, the latest version of Cypress is 12.2.0.

Once the setup is done, open the Cypress, which will open with all default .spec files.

To perform end-to-end testing using Cypress, follow the blog on Cypress end to end Testing to know in detail.

In the next section of this blog on Playwright vs Selenium vs Cypress, we will learn about different runners available for Playwright, Selenium, and Cypress.

Check this out: Minify JSON helps to minify, compress and reformat JSON data. Just load your JSON and it will automatically get minified.

Runner

Runner is a tool you can use to run/execute test cases. After executing the test cases, you can view and export the test execution results.

Playwright:

Playwright has its runner and has the adaptability to operate with third-party runners such as Playwright Test Jest / Jasmine, AVA, Mocha Vitest, and multiple browsers. You can connect Playwright to your current JavaScript test runner with a few lines of code.

Playwright Test: First-party suggested test runner for Playwright is called Playwright Test.
Jest/Jasmine: You can use jest-playwright for Jest. However, requiring the Playwright directly works well as a simple approach. This also applies to Jasmine, which has a shared syntax with Jest.
**AVA: **A single page variable cannot be shared between tests in AVA since tests run concurrently. Use a macro function to create new pages instead.
**Mocha: **Mocha functions similarly to the Jest/Jasmine configuration and has a similar appearance.
Vitest: Vitest looks similar to the Jest/Jasmine setup and functions similarly.
Multiple Browsers: We can execute the test cases using an environment variable in multiple browsers.

In Playwright, we can run a single test case/set of test cases or all test cases. By default, test cases are run in headless mode. Test cases are run in the terminal, and results can only be seen in the terminal. Below are the commands that we can use to run the test cases.

Performing Playwright browser testing in headless mode:


    npx playwright test

Running a single Playwright test case:

   npx playwright test fileName.spec.js

Run a set of Playwright test cases:

 npx playwright test tests/page/home-page/

Running Playwright tests in headed mode:

    npx playwright test home-page.spec.js --headed

In Playwright, you can run the test case in debug mode. Playwright has a built-in tool, i.e., Playwright Inspector, which permits you to step via Playwright API calls, see their debug logs, and explore selectors. The Playwright Inspector also helps in finding the locators. We can find the locator by hovering over the element during the inspection.

In debug mode, Playwright opens the “Playwright Inspector,” where we can go line-wise and easily check the reason for the failure of the test case in the Inspector itself.

Selenium:

Selenium Runner is a command-line tool that allows you to run Selenium scripts. There are several runners available for Selenium, each with its own set of features and capabilities. Below is a list of a few runners normally used to run test cases in Selenium.

Selenium WebDriver: This is the most widely used runner for Selenium. It allows you to automate web browser actions, such as clicking on elements, filling out forms, and navigating between pages.
Selenium Grid: This runner allows you to run your Selenium scripts on a remote machine or in the cloud. It is useful for running tests in parallel on multiple machines and different browsers and operating system configurations.
**TestNG: **This is a popular testing framework often used with Selenium. It allows you to create test cases, define test suites, and support running tests in parallel.
**JUnit:** This is another popular testing framework often used with Selenium. It allows you to create test cases, define test suites, and support running tests in parallel.
**Jenkins: **This is a continuous integration tool that can run your Selenium tests. It automates the build, test, and deployment process and supports running tests in parallel.
**Maven: **This is a build automation tool that can be used to manage your Selenium tests. It allows you to define dependencies, build and test your code, and manage the deployment process.

Cloud testing tools like LambaTest can be used as a test case runner to execute automated tests on a variety of different operating systems, browsers, and devices. With LambdaTest, you can run end-to-end automated tests using Selenium on a safe, dependable, and scalable Selenium infrastructure. This can help users to ensure that their websites and applications are compatible with a wide range of different platforms and devices and to identify and fix any issues that may arise.

Using LambdaTest, you can automate cross browser testing on more than 3000 distinct operating systems and browsers with Selenium scripts, which leads to greater test coverage and significantly quicker build times.

Cypress:

Cypress has a test runner where we can see the executing commands. Apart from that, in Cypress, you can see the application under test with real-time data. Using Cypress runner, you can see the change in UI after hovering over the log in the command log.

Run your Cypress automation scripts across 3000+ environments. Try LambdaTest Now!

Check this out: JSON Escape removes offending characters that can cause parsing errors. Special characters such as quotes, newlines and backslashes will be replaced with their escaped counterparts.

Record & Playback

When comparing Playwright vs Selenium vs Cypress, most tools typically have a record and playback feature, which is quite beneficial for first-time users. You can change an existing test, record new tests, and run the recorded steps using the Record & Playback tool.

All three tools, i.e., Playwright vs Selenium vs Cypress, include Record & Playback, which are described in more depth below.

Playwright:

In Playwright, you will generate the code for the user interactions. You can use CodeGen to generate the actions we perform in the browser. Playwright will generate the code for the user action performed. You can use the below commands to open the Playwright Inspector.

In the below screenshot, you can see code is generated when you click on the Home, Blog, and Mega Menu link.


    npx playwright codegen https://ecommerce-playground.lambdatest.io.

Selenium:

We have Selenium IDE to record and playback the code in Selenium. Selenium IDE doesn’t need any additional setup before usage other than installing the plugin in your browser.

It does not require any programming logic to develop its test scripts, unlike Selenium WebDriver and RC. Instead, you may only record your browser interactions to create test cases. The playback option can then be used to rerun the test scenarios.

Selenium IDE records multiple locators for every element it interacts with. It tries to attempt the locator until one is successful if one fails during playback. You can reuse existing test cases inside of another by using the run command (e.g., allowing you to reuse your login logic in multiple places throughout a suite). In the below screenshot, you can see we have reused VerifyHomePage test steps in another test case.

The Selenium IDE comes preloaded with a robust control flow structure that includes available commands like if, while, and times.

Cypress:

We can use Cypress Studio to capture the test case in Cypress. By capturing interactions with the application being tested, Cypress Studio offers a visual approach to developing tests within Cypress.

Cypress Studio provides a visual approach to create tests within Cypress by recording interactions against the application under test. When interacting with the DOM inside of Cypress Studio, the .type().click(),.check(),.uncheck(), and .select() Cypress commands are available and will produce test code.

To enable the Cypress Studio, we have to do the below setting (experimentalStudio: true) in cypress.config.js.

   const { defineConfig } = require("cypress");
    module.exports = defineConfig({
     e2e: {
       experimentalStudio: true,
     },
    });

After doing the above setting when we run the test cases. We can see two options to record the test cases:

Add New Tests.
Add commands to Test.

Add New Tests

Using Add New Test, we can add a new Test, save it and re-run it. In the below screenshot, we can see steps are recorded by Cypress Studio. Just save the commands, and a new script is created.

Add commands to Test

Using Add commands to Test, we can add more steps in existing test cases.

In the screenshot below, you can see whatever steps added in the first test case are recorded on an existing script. This way, we can update our existing script with new additional steps.

    /// <reference types="cypress" />
    describe("Cypress Studio -- >", { testIsolation: false }, () => {
     it("WHEN User Open the Url", () => {
       cy.visit(
         "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
       );
       /* ==== Generated with Cypress Studio ==== */
       cy.get('#widget-navbar-217834 > .navbar-nav > :nth-child(1) > .icon-left > .info > .title').click();
       cy.get('#widget-navbar-217834 > .navbar-nav > :nth-child(3) > .icon-left > .info > .title').click();
       /* ==== End Cypress Studio ==== */
     });
     it("AND Login into the application", () => {
       cy.get('[id="input-email"]').type("lambdatest@yopmail.com");
       cy.get('[id="input-password"]').type("lambdatest");
       cy.get('[type="submit"]').eq(0).click();
     });
     it("AND After login Search the Product", () => {
       cy.get('[name="search"]')
         .eq(0)
         .type("Sony VAIO")
         .should("have.value", "Sony VAIO");
       cy.get('[type="submit"]').eq(0).click();
     });
     it("THEN Verify Correct Product should display after search ", () => {
       cy.contains("Sony VAIO");
     });
    });

In the next section of this blog on Playwright vs Selenium vs Cypress, we will learn about different ways to select elements in Playwright, Selenium, and Cypress.

Check this out: Unescape JSON removes traces of offending characters that could prevent parsing. To unescape JSON strings, several libraries and tools are available in different programming languages.

Element Selection

Element selection is a way where we filter out all elements with a given tag in documents and make sure the element you are making assertions is detached from the DOM. We have different types of tags (e.g., Id, CSS, Class, Attribute, Tag Name, Link Text, Name Attribute)

Playwright:

In Playwright, we have an auto-wait concept that makes the command fast and the test case execution fast. Playwright auto-waits for all the relevant checks to pass. Once these checks pass, then only perform the requested action.

Here is the list of actionability checks performed for each action on the elements.

ACTION	ATTACHED	VISIBLE	STABLE	RECEIVES EVENTS	ENABLED	EDITABLE
check	Yes	Yes	Yes	Yes	Yes	–
press	Yes	–	–	–	–	–
setInputFiles	Yes	–	–	–	–	–
selectOption	Yes	Yes	–	–	Yes	–
textContent	Yes	–	–	–	–	–
type	Yes	–	–	–	–	–
click	Yes	Yes	Yes	Yes	Yes	–
dblclick	Yes	Yes	Yes	Yes	Yes	–
setChecked	Yes	Yes	Yes	Yes	Yes	–
tap	Yes	Yes	Yes	Yes	Yes	–
uncheck	Yes	Yes	Yes	Yes	Yes	–
hover	Yes	Yes	Yes	Yes	–	–
scrollIntoViewIfNeeded	Yes	–	Yes	–	–	–
screenshot	Yes	Yes	Yes	–	–	–
fill	Yes	Yes	–	–	Yes	Yes
selectText	Yes	Yes	–	–	–	–
dispatchEvent	Yes	–	–	–	–	–
focus	Yes	–	–	–	–	–
getAttribute	Yes	–	–	–	–	–
innerText	Yes	–	–	–	–	–
innerHTML	Yes	–	–	–	–	–

Below are the points that the Playwright will ensure before taking action on any of the elements on the page.

element is bound to the DOM
element is visible
element is enabled
element receives events, as in not obscured by other elements

Below are a few examples of Playwright. In the case of the Playwright, “waits” is included by default against each action on the element.

   await page.goto('https://www.bing.com')
    const element = await page.$('[aria-label="Enter your search term"]')
    await element.click()
    await element.type('LambdaTest')
    await element.press('Enter')

    await page.locator('text=Log in').click();
    await page.locator('article:has-text("Playwright")').click();
    await page.locator('#nav-bar >> text=Contact Us').click();

Check this out: With this free online Alder32 Hash Calculator, you can provide input in plain text, Base64, or as a binary file. Hit the Calculate button above and voila! Your Adler-32 checksum will be generated in no time.

Selenium:

WebElements in Selenium are used to interact with DOM elements. We normally used different types of locators (mentioned above) to connect with the page’s elements. Sometimes when we search for the element, we assume that the element will already be loaded on the page.

In my opinion, this is one of Selenium’s biggest limitations. As a result of the test frequently failing after repeated attempts to find the element, we must start loading the element with implicit or explicit waits to avoid flakiness.

To avoid failure of the test case, here we check whether the element is available in DOM.

    WebElement button = new WebDriverWait(driver, 30).until(ExpectedConditions.presenceOfElementLocated(By.id("buttonId")));
    button.click();

Cypress:

In the case of Cypress, things are the opposite, as interactions of elements are done through the locators. There is an inbuilt “wait mechanism” in Cypress, which makes the execution of the tests much more stable and decreases the flakiness during the execution of the test cases.

This duration is configured by the defaultCommandTimeout option — which has a default of 4000 ms. This means that when acting on the element, Cypress will wait up to 4 seconds to move to the next command. You will get an error message if the element is not loaded within the default time. We can increase defaultCommandTimeout from cypress.config.js file

     const { defineConfig } = require('cypress')

    module.exports = defineConfig({
     defaultCommandTimeout: 10000
    })

Cypress automatically pauses for the network call to complete before moving to the next command. In the below commands of Cypress, for every command, Cypress will wait for 4 seconds.

    cy.get('.btn').click() // Click on to the button
    cy.focused().click() // Click on element with focus
    cy.contains('Welcome').click() // Click on first el containing 'Welcome'

Check this out: HTML Escape is a simple tool that turns normal HTML into escaped HTML, making it easier to display HTML text in the pre> tag.

Language/Browser Support

Language/browser support is one of the key differentiators among Playwright vs Selenium vs Cypress.

Playwright:

It supports most languages, including Python, Java, Java Script, and .Net. Playwright has the full support of all modern browsers that include Google Chrome and Microsoft Edge (with Chromium), Safari (with WebKit), and Firefox.

Selenium:

Selenium is a suite of tools that enables automated testing of web applications. It supports various programming languages, including Java, Python, C#, Ruby, and JavaScript. You can use any of these languages to write your Selenium test scripts, and run them on various web browsers, including Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, and Safari. Selenium also provides support for headless browsers, which allow you to run your tests without actually launching a web browser window.

To use Selenium with a particular programming language and web browser, you must install the appropriate language bindings and WebDriver. These will allow you to interact with the browser and perform actions such as navigating a web page, clicking on elements, and entering text.

For example, if you want to use Selenium with Python and Chrome, you must install the Python bindings for Selenium and the ChromeDriver web driver. You can then use the Python bindings to control Chrome and perform your tests.

Cypress:

Cypress is a JavaScript-based end-to-end testing tool designed to work with web applications. As a result, it is primarily designed to work with web pages and applications written in HTML, CSS, and JavaScript. It is compatible with all modern browsers, including Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari.

Check this out: The html unescape method helps us to convert the ascii string into html script by replacing ascii characters with special HTML characters. This tool will convert HTML entities to a string or convert plain text to HTML entities.

Parallel Execution

Parallel execution is a crucial feature for automating web browsers as it allows running multiple test cases simultaneously, thus reducing the overall execution time. When it comes to parallel execution, Playwright, Selenium, and Cypress are all popular choices among developers.

In this comparison, we will take a look at how each of these tools handles parallel execution, what kind of parallel execution options they offer, and how easy it is to implement parallel execution with these tools.

Playwright:

When it comes to comparing Playwright vs Selenium vs Cypress, Playwright supports parallel execution across multiple machines.
Let’s take an example to run the test cases in parallel.

Below is the code snippet where we are opening one eCommerce website, then clicking on the Home, Blog link, and verifying the user is redirected to the correct URL.

    // @ts-check
    const { test, expect } = require("@playwright/test");

    test.describe("Test suite", () => {
     test.beforeEach(async ({ page }) => {
       await page.goto("https://ecommerce-playground.lambdatest.io/");
     });
     test("Open the Lambdatest Site Click on Home Link and verify user re-direct to correct url", async ({ page }) => {
       await page.locator('span:has-text("Home")').click();
       await expect(page).toHaveURL(
         "https://ecommerce-playground.lambdatest.io/index.php?route=common/home"
       );
     });
     test("Open the Lambdatest Site Click on Blog Link and verify user re-direct to correct url", async ({ page }) => {
       await page.locator("#widget-navbar-217834 >> text=Blog").click();
       await expect(page).toHaveURL(
         "https://ecommerce-playground.lambdatest.io/index.php?route=extension/maza/blog/home"
       );
     });
    });

Running the script with 1 Worker in Playwright:

In below screenshot, we can see we have 2 test cases that are running one by one [1/2].

Here we can see that when we were running test cases in a Single worker, it took 16s.

By default, test cases are run in a single worker, but if we have to run the test cases in parallel in different machines, we have to provide the number of workers either through the command line by updating the config file passing npx playwright test --workers 4 where “4” is the number of workers on which we want to execute our test cases.

Another way to run the test cases in parallel is by bypassing the worker in playwright.config.js.

Setting to update the Worker

To update the number of workers, we have to update playwright.config.js. In the below screenshot, you can see I have updated the worker to “2” in line number #33.

Running the script with 2 Workers in Playwright:

In the below screenshot, we can see both the test cases are executed parallelly [2/2].

When we run the same script with 2 workers taking 13s.

LambdaTest allows you to perform parallel testing with Playwright across 50+ browsers and OS to automate your several test cases simultaneously. You can run one test case across various browsers or multiple test case scenarios in the same browser with different browser versions.

Subscribe to LambdaTest YouTube Channel and stay updated with detailed tutorials around Playwright testing, Selenium testing, Cypress testing, and more.

Check this out: An MD4 hash calculator is a tool that calculates the MD4 hash value of a file or data.

Selenium:

Parallel execution means executing the test case of different modules in parallel instead of running them in series. In Selenium, you can do parallel execution using TestNG. Below is the structure for defining the attribute in the TestNG XML file to run the test cases in parallel.


    <suite name=”ParallelTesting” parallel=”methods” thread-count=”3">

In the above example, in place of “method,” we can pass the below values.

Below pointer mentioned here is specific to Java. It might vary for other Selenium-supported languages.

Methods: All the methods with @test annotation will run in parallel.
Instances: Helps execute all methods in the same instance in the same thread.
Tests: All the test cases inside the tag of the Testing XML file will run parallel.
Classes: All the test cases inside a Java class will run in parallel.
Thread Count: No of threads you want to run in parallel.

In the above code snippet, attribute thread count helps in defining the number of threads that we want while executing the test cases in parallel.

Let’s take an example of how a thread works. Suppose we have three methods and two threads to run the test cases in parallel. So initially, two methods will run with two available threads. Once any thread between two freezes, the third method in the queue starts executing.

Let’s Take an example to run the test cases in parallel. Open the Site https://ecommerce-playground.lambdatest.io/, Verify the title, Click on the Home Page, and Verify the user is redirected to the correct URL.

Create three Classes, “ChromeParallelTest,” ”ForefoxParallelTest,” and “SafariParallelTest” to run the test cases in three browsers.

Below is the code snippet for Class “ChromeParallelTest”:

    package ParallelTestCase;

    import org.openqa.selenium.By;
    import org.openqa.selenium.WebDriver;
    import org.openqa.selenium.WebElement;
    import org.openqa.selenium.chrome.ChromeDriver;
    import org.testng.Assert;
    import org.testng.annotations.AfterClass;
    import org.testng.annotations.BeforeTest;
    import org.testng.annotations.Test;

    public class ChromeParallelTest {

     WebDriver driver;

     @BeforeTest
     public void setUp() {
       System.setProperty("webdriver.chrome.driver", "/Users/xxxxx/Desktop/Chromedriver/chromedriver");
       driver = new ChromeDriver();
       driver.navigate().to("https://ecommerce-playground.lambdatest.io/");
       driver.manage().window().maximize();
     }

     @Test
     public void VerifyTitle() {
       System.out.println("The thread ID for Running First Test In Chrome Browser is  " + Thread.currentThread().getId());
       Assert.assertEquals(driver.getTitle(), "Your Store");
     }

     @Test
     public void ClickOnHomeLink() {
       System.out.println("The thread ID for Running Second Test In Chrome Browser is  " + Thread.currentThread().getId());
       WebElement homeLink = driver.findElement(By.xpath("//span[contains(text(),'Home')]"));
       homeLink.click();
       String redirectURL = driver.getCurrentUrl();
       Assert.assertEquals(redirectURL, "https://ecommerce-playground.lambdatest.io/index.php?route=common/home");
     }

     @AfterTest
     public void close() {
       driver.quit();
     }
    }

Below is the code snippet for the Class “FirefoxParallelTest”.

    package ParallelTestCase;

    import org.openqa.selenium.By;
    import org.openqa.selenium.WebDriver;
    import org.openqa.selenium.WebElement;
    import org.openqa.selenium.firefox.FirefoxDriver;
    import org.testng.Assert;
    import org.testng.annotations.AfterClass;
    import org.testng.annotations.BeforeTest;
    import org.testng.annotations.Test;

    public class FirefoxParallelTest {

     WebDriver driver;

     @BeforeTest
     public void setUp() {
       System.setProperty("webdriver.chrome.driver", "/Users/xxxxxxx/Desktop/Chromedriver/chromedriver");
       driver = new FirefoxDriver();
       driver.navigate().to("https://ecommerce-playground.lambdatest.io/");
       driver.manage().window().maximize();
     }

     @Test
     public void VerifyTitle() {
       System.out.println("The thread ID for Running First Test In Firefox Browser is " + Thread.currentThread().getId());
       Assert.assertEquals(driver.getTitle(), "Your Store");
     }

     @Test
     public void ClickOnHomeLink() {
       System.out.println("The thread ID for Running Second Test In Firefox Browser iss " + Thread.currentThread().getId());
       WebElement homeLink = driver.findElement(By.xpath("//span[contains(text(),'Home')]"));
       homeLink.click();
       String redirectURL = driver.getCurrentUrl();
       Assert.assertEquals(redirectURL, "https://ecommerce-playground.lambdatest.io/index.php?route=common/home");
     }

     @AfterTest
     public void close() {
       driver.quit();
     }
    }

Below is the code snippet for Class “SafariParallelTest”.

    package ParallelTestCase;

    import org.openqa.selenium.By;
    import org.openqa.selenium.WebDriver;
    import org.openqa.selenium.WebElement;
    import org.openqa.selenium.firefox.FirefoxDriver;
    import org.testng.Assert;
    import org.testng.annotations.AfterClass;
    import org.testng.annotations.BeforeTest;
    import org.testng.annotations.Test;

    public class SafariParallelTest {

     WebDriver driver;

     @BeforeTest
     public void setUp() {
       System.setProperty("webdriver.chrome.driver", "/Users/xxxxxx/Desktop/Chromedriver/chromedriver");
       driver = new SafariDriver();
       driver.navigate().to("https://ecommerce-playground.lambdatest.io/");
       driver.manage().window().maximize();
     }

     @Test
     public void VerifyTitle() {
       System.out.println("The thread ID for Running First Test In Firefox Browser is " + Thread.currentThread().getId());
       Assert.assertEquals(driver.getTitle(), "Your Store");
     }

     @Test
     public void ClickOnHomeLink() {
       System.out.println("The thread ID for Running Second Test In Firefox Browser iss " + Thread.currentThread().getId());
       WebElement homeLink = driver.findElement(By.xpath("//span[contains(text(),'Home')]"));
       homeLink.click();
       String redirectURL = driver.getCurrentUrl();
       Assert.assertEquals(redirectURL, "https://ecommerce-playground.lambdatest.io/index.php?route=common/home");
     }

     @AfterTest
     public void close() {
       driver.quit();
     }
    }

To run the test cases in parallel, let’s create a testng.xml file with the following config.

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
    <suite name="Suite" parallel="tests" thread-count="2">
    <test name="Parallel Test Case Execution In Chrome">
       <classes>
         <class name="ParallelTestCase.ChromeParallelTest"/>
       </classes>
     </test> <!-- Test Case END -->
      <test name="Parallel Test Case Execution In FireFox">
       <classes>
         <class name="ParallelTestCase.FirefoxParallelTest"/>
       </classes>
     </test> <!-- Test Case END -->

     <test name="Parallel Test Case Execution In Safari">
       <classes>
         <class name="ParallelTestCase.SafariParallelTest"/>
       </classes>
     </test> <!-- Test Case END -->
     </suite> <!-- Suite END -->

In the above screenshot, we can see we have given thread-count “2”. So the first two test cases are run in two threads. Once the threads are free, the next test case starts executing.

Let’s execute the test cases. We have to right-click on testng.xml and then “Run As” -> TestNG Suite.

You can see in the screenshot below that “FirefoxTest” and “ChromeTest” were running concurrently on Threads 15 and 16, respectively, as seen in the console logs. Later, “SafariTest” was executed on Thread 15 because it was released before 16.

Run your Selenium automation scripts across 3000+ environments. Try LambdaTest Now!

Cypress:

Cypress supports parallel execution across multiple machines from version 3.1.0. By default, the cypress run command executes the test cases serially. In Cypress, we can execute test cases in parallel, which saves your team time and good ROI when running tests in Continuous Integration (CI) tests.

To run Cypress test cases locally, we can use the command npx cypress run –record –key xxxxxx-xxx-xxxx0-xx-xxxxx. Record Keys allow you to record test results, screenshots, and videos in Cypress.

Let’s run the below Cypress test case in Cypress Cloud for the site https://ecommerce-playground.lambdatest.io/.

    describe("Verify title of ecommerce-playground.lambdatest.io", function () {
     it("Should display the correct title", function () {
       cy.visit("https://ecommerce-playground.lambdatest.io/");

       cy.title().should("include", "Your Store");
     });
     it("Should navigate to the Blog page", function () {
       cy.visit("https://ecommerce-playground.lambdatest.io/");

       cy.contains("Blog").click({ force: true });

       cy.url().should("include", "/blog/");
     });
    });

When we run the above test case using the command npx cypress **run –record –key xxxxxx-xxx-xxxx0-xx-xxxxx. **The test case starts running in Cypress cloud.

In the below screenshot, we can see the test case running in 1 machine.

To run the Cypress test case in parallel, we must connect the Cypress cloud with CI/CD. There are numerous CI/CD solutions supported by Cypress, and they are simple to connect with Cypress cloud. To run tests with GitHub Actions, you can refer to this blog on how to run Cypress tests with GitHub Actions.

Cloud-based cross browser testing solutions like LambdaTest allow you to test your web application or website across a wide range of desktop and mobile browsers. One of the features of LambdaTest is the ability to perform parallel testing, which allows you to run multiple tests simultaneously, significantly reducing the time it takes to complete your testing.

When using LambdaTest and Cypress together, you can use the LambdaTest platform to run your Cypress tests across a wide range of browsers and devices in parallel, reducing the time it takes to complete your testing. You can read through this blog to perform Cypress testing with LambdaTest Cypress CLI

In the next section of this blog on Playwright vs Selenium vs Cypress, we will learn about how to handle flakiness in test automation frameworks like Playwright, Selenium, and Cypress.

Check this out: The MD2 Hash Generator creates a unique string of characters that functions as a password or key.

Flakiness

A test is considered flaky when it can pass and fail across multiple retry attempts without any code changes.

As one of the Google blogs says — Almost 16% of our tests have some flakiness associated with them! This is a staggering number; more than 1 in 7 of the tests written by our world-class engineers occasionally fail in a way not caused by changes to the code or tests.

In one of the research, it was found that 72 percent of test failures are false positives. Think about all the tests you have and all the test failures reported for each run. False positives consume a lot of resources that could be dedicated to much more valuable work.

Check this out: The free online line counter tool is used to count the number of lines in a document or passage of text. It allows you to count lines with or without blanks.

Playwright:

There are many ways to handle the flakiness in Playwright. Following are some best ways of handling the flakiness in Playwright.

Auto-wait feature In Auto-wait, we make sure when you perform an action, like clicking on the element, selecting a value, and entering the data on the text field, the element should be loaded before the action is performed.

Below is a code snippet with the assertion:

    test("Verify button enable or not", () => {
       const submit = page.locator("button", {hasText: "Previous"});
       // Will check  button is enabled or not
       expect(await submit.isEnabled()).toBeTruthy()
       await submit.click();
    })

In the above code, we don’t need the below line; you are just wasting testing time on a non-necessary assertion. The playwright has an auto-wait mechanism and automatically handles the assertion part.

expect(await submit.isEnabled()).toBeTruthy()

   test("Verify button enable or not", () => {
       const submit = page.locator("button", {hasText: "Previous"});
       // Will check  button is enabled or not
       await submit.click();
    })

Use Methods like waitForLoadState waitForNavigation waitForSelector to avoid flakiness.

We can use these methods to avoid the flakiness. Using these methods, we can make sure the page is fully loaded before it interacts with the element on the page.

Method waitForLoadState is used to wait till a specific state of the page has been reached.
Method waitForNavigation is suggested when Before beginning navigation, clicking an element may cause asynchronous processing to take place.
Method waitForSelector used to hold off till the selector satisfies the state option (e.g either appear/disappear from the DOM, or become visible/hidden).

    await page.waitForLoadState('domcontentloaded', { timeout: 1000 });
    await page.waitForLoadState('networkidle', { timeout: 5000 });
    await page.waitForLoadState('load', { timeout: 2000 });

    await Promise.all([
     page.waitForNavigation({ url: '**/login' }),
     page.click('button'), 
    ]);

    await page.waitForSelector('.myDiv')

Another feature using which we can avoid flakiness is Retries.

Sometimes when the page loads for the first time, the required element is not present, and test cases fail. We can avoid this situation by using the Retries option. We can provide the Retries option in the Playwright.config.js file so that when test cases fail, the system will retry again, and the probability of the test case passing is increased.

   const config = {
       // Give failing tests 2 retry attempts
       retries: 2,
     }

Selenium:

In Selenium, test cases can be flaky due to the flakiness in the test code or the flakiness in the test infrastructure. Flakiness on the infrastructure front can be avoided by moving test execution to a cloud platform like LambdaTest.

A flaky test is a test that randomly passes or fails for the same code, giving inconsistent results. One time it passes; another time, it fails; and the next time, it passes without any change being made to the build.

There are several ways to avoid flakiness in Selenium tests:

Use stable selectors: Instead of using dynamic selectors such as XPath, try to use stable selectors such as class name or Id to locate elements. Dynamic selectors can be affected by changes in the structure of the HTML, leading to test flakiness.
Use explicit waits: Instead of using implicit waits, use explicit waits to allow the page to load and stabilize before interacting with elements. This can help prevent tests from failing due to elements not being immediately available.
Add retry logic: Implement retry logic in your tests to retry failed assertions a certain number of times before giving up. This can help reduce flakiness caused by temporary network or server issues.
Use a stable testing environment: Make sure your tests run in a stable environment with consistent network and server conditions.
Debug failing tests: When tests fail, take the time to debug and understand the root cause of the failure. This can help you identify and fix underlying issues that are causing flakiness.
Use a test framework: Use a test framework such as JUnit or TestNG to structure your tests and provide built-in support for handling test failures. This can make it easier to identify and debug failing tests.
Use a reliable testing framework: Use a reliable testing framework, such as JUnit or TestNG, to manage the execution of tests and handle any issues that may arise.
Use a reliable continuous integration (CI) server: Use a reliable CI server, such as Jenkins or Azure DevOps, to run tests automatically and track the results of test runs.

One way to use a cloud platform like LambdaTest to avoid flakiness in Selenium is to run your Selenium scripts on the cloud infrastructure instead of running them locally on your machine.

Cypress:

Cypress handles flakiness very well. In Cypress, there are different ways of handling flakiness.

Following are some best ways of handling the flakiness in Cypress.

Adding .contains('element') .should('be.visible'),.should('exist') before clicking on element.
Test Retires
Use timeouts instead of waits.
Use cy.intercept() to wait for the XHR request to finish execution.

The first and very straightway method to reduce the flakiness is by using .should('exist') .should('be.visible') .contains('element'). These assertions reduce the chance of test case failure.
The second method in Cypress to reduce the flakiness is to use Test Retires. You can set the Test Retires option at Global Configuration, Individual Test, or Test Suite level.

Another way to reduce the flakiness is to use timeouts instead of waits.

Sometimes, we have required a higher timeout for a particular element to load into the page. You can handle such cases by providing a timeout on a particular element instead of using cy.wait().

The difference between cy.wait() and set the timeout at the field level is, in the case of cy.wait() Cypress will wait for the complete time that we have provided under cy.wait(), but in case of timeout, if the element load before the specified timeout, Cypress will move to the next command to execute. This way, sometimes timeout is effective as it saves time.


    cy.get(“#first-name”, {timeout: 10000}).type(“Mike”)

We can use cy.intercept() to wait for the XHR request to finish execution. We can intercept the particular network call and wait till the call is not finished.

In the below screenshot, after clicking on the form model, we presume there is some unfinished request. cy.wait() wait for the request/response cycle to complete. By using the cy.wait("@getModel") we have access to the XHR object. Cypress will wait for the API call to end before moving forward as long as the request is not finished. So you can prevent test cases from failing in this manner.

Check this out: This online MD5 hash generator is a tool for encoding passwords, credit card numbers, and other sensitive data into MySQL, Postgress, and similar databases.

Screenshots

Screenshots play a very important role when test cases fail regularly. The screenshot gives an idea about the steps where test cases fail and help you make the test case less flaky.

Playwright:

While comparing Playwright vs Selenium vs Cypress, it is very easy to take screenshots in Playwright. There are three ways to take a screenshot.

Full page screenshots
Capture into buffer
Element screenshot

Full page screenshots

To take Full page screenshots, we have to write the below code:

    await page.screenshot({ path: ‘screenshot.png’, fullPage: true });

Capture into buffer

Instead of writing into a file, you can get a buffer with the image and post-process it or pass it to a third-party pixel diff facility.

    const buffer = await page.screenshot();
    console.log(buffer.toString('base64'));

Element screenshot

We can take the screenshot at the element level too, using the below code.

   await page.locator(‘.header’).screenshot({ path: ‘screenshot.png’ });

Selenium:

A screenshot in Selenium WebDriver is helpful for bug investigation. In Selenium, if you want to take the screenshot during execution, you can use the TakesScreenshot method, which informs the WebDriver to grab the screenshot.

Code snippet to take the screenshot of the Page attached below.

    import org.apache.commons.io.FileUtils;
    import org.openqa.selenium.OutputType;
    import org.openqa.selenium.TakesScreenshot;
    import org.openqa.selenium.WebDriver;
    import org.openqa.selenium.chrome.ChromeDriver;
    import java.io.File;
    import java.io.IOException;

    public class ScreenshotCapture {
       public static void main(String[] args) {
           //set the location of chrome browser
           System.setProperty("webdriver.chrome.driver", "C:\\chromedriver.exe");
           // Initialize the browser
           WebDriver driver = new ChromeDriver();
           //navigate to the url
           driver.get("https://www.lambdatest.com/");
          //Take screenshot
           File screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);
           //Copy the file to a location
           try {
               FileUtils.copyFile(screenshot, new File("C:\\xxx\\xxx.png"));
           } catch (IOException e) {
               System.out.println(e.getMessage());
           }
           //closing the webdriver
           driver.close();
       }
    }

We can take screenshots of elements in Selenium. Code Snippet to take the screenshot of the element attached below.

   import org.apache.commons.io.FileUtils;
    import org.openqa.selenium.*;
    import org.openqa.selenium.chrome.ChromeDriver;
    import java.io.File;
    import java.io.IOException;

    public class SeleniumelementTakeScreenshot {
     public static void main(String args[]) throws IOException {
       WebDriver driver = new ChromeDriver();
       driver.get("https://www.lambdatest.com/");
       WebElement element = driver.findElement(By.cssSelector("h1"));
       File scrFile = element.getScreenshotAs(OutputType.FILE);
       FileUtils.copyFile(scrFile, new File("./image.png"));
       driver.quit();
     }
    }

Cypress:

Cypress has an in-built ability to take screenshots. You can run test cases via “cypress open” OR “cypress run”. You can use cy.screenshot() if you want to take screenshots manually.

Capturing screenshots when a test fails can be turned off completely by specifying screenshotOnRunFailure to false from within the Cypress configuration or by specifying screenshotOnRunFailure to false in the Cypress.Screenshot.defaults().

Below are different syntaxes to capture the screenshot in Cypress.

    cy.screenshot()
    cy.screenshot(fileName)
    cy.screenshot(options)
    cy.screenshot(fileName, options)

In the below Code snippet, you can see the screenshot saved by default under the screenshots folder when test cases are failing.

    // cypress/e2e/login.cy.js

    describe('Screenshot tests', () => {
       it('takes a screenshot', () => {
         // screenshot will be saved as
         // cypress/screenshots/login.cy.js/Screenshot tests -- takes a screenshot.png
         cy.screenshot()
       })
     })

By default, screenshot capture is true. However, you can disable it by the following setting under the support/index.js file.

    Cypress.Screenshot.defaults({
     screenshotOnRunFailure: false,
    })

Check this out: RIPE MD 320 Hash Generator - The goal of using a cryptographic hash function, such as RIPEMD-320, is to take an input (or “message”) and generate a fixed-length string of characters, known as the “hash value,” that is unique to the input. This can be used for many things, including digital signatures, message authentication, and data integrity.

Video

Video features help in finding the bug and make debugging easy when there is the failure of the test case. Since we can watch what happens when a series of test steps are running, it becomes very easy to track down the exact step when some test case fails. Here we are comparing Playwright vs Selenium vs Cypress to see how we can take videos using these frameworks.

Playwright:

In the Playwright video of test cases handled by the “video” option in the config file. By default videos are off.

    // @ts-check
    /** @type {import('@playwright/test').PlaywrightTestConfig} */
    const config = {
     use: {
       video: 'on-first-retry',
     },
    };
    module.exports = config;

In option video, we can pass the below parameter

“off” — Do not record video.
“on” — Record video for each test.
“retain-on-failure” — Record video for each test, but remove all videos from successful test runs.
“on-first-retry” — Record video only when retrying a test for the first time.

Selenium:

Selenium WebDriver does not have any built-in mechanism to record videos of the test cases that are executed. In Selenium, to capture the video, we have extensions available. Using these extensions, we can record the test case execution steps, and when some of the test cases fail to record, it is helpful to know the exact reason for test step failure.

Cypress:

Cypress records the video automatically of every .spec file. When we run the command cypress run video of each .spec file is recorded. Videos are saved automatically under the folder cypress/videos. We can turn off the video entirely by making the flag video: **false **in the configuration file.

Run your Playwright automation scripts across 3000+ environments. Try LambdaTest Now!

Check this out: A sentence Counter is a tool to determine how many sentences make up a given article or document.

iFrame

iFrame is an HTML element that embeds another document within the current HTML document. Using iFrames, you can add content from another website to a web page. It allows you to engage users by supplementing your content, including sharing and embedding YouTube videos and external photos.

Below is the syntax for iFrame:

    <iframe id="parent_iframe" name="demo_parent_iframe" width="700" height="450" src="https://bit.ly/38erOdQ"> 
    </iframe>

Below screenshot is the example of Nested iFrame where we have Parent and Child both iFrame. The screenshot below shows the “Click Here” button in the Parent and Child iFrame.

Playwright:

When testing iFrames in Playwright, we can use the method FrameLocator, which allows us to retrieve the iFrame and locate elements inside that iFrame. FrameLocator captures the logic sufficient to retrieve the iFrame and locate elements in that iFrame.

Let’s take a simple example:
Let us now launch https://the-internet.herokuapp.com/iframe. We have to enter the data in the text area, which is under the iFrame.

Inspect the text area of this frame. Notice below that it is represented by the tag ‘iframe’ having the ‘id’ mentioned below.

We have a method called “frameLocator” in the Playwright, as seen below. Using this method, we can identify the above frame that we have inspected.

Here we are using the CSS Selector to identify the frame

    const frame1 = page.frameLocator(‘#mce_0_ifr’).locator(‘html’)

Once we have located the frame, we have to click it before we start typing into it. Code snippet attached below

    import {test,expect} from '@playwright/test'

    test("frames", async ({ page }) => {
      await page.goto('https://the-internet.herokuapp.com/iframe')
      const frame1 = page.frameLocator('#mce_0_ifr').locator('html')
       await frame1.click()   
      await frame1.type('Welcome to playwright')
       await page.pause()   
    })

Selenium:

Selenium is capable of working with iFrames in a simple way. In the case of Selenium, we have to move to the iFrame window and do all activities that you want to do. Once all actions are done, then move back to the main page of the application to do further actions.

By default, Selenium has access to the parent browser driver. The driver focus must change from the main browser window to the frame to access a frame element.

There are various ways to switch to frames.

switchTo().frame(id) — The frame’s id or name is passed as input to the switchTo() method.
switchTo().frame(i) — The index of the frame is passed as an argument. The index starts from zero.
switchTo().frame(webelement n) — The webelement of the frame is passed as an argument.
switchTo().defaultContent() — Switching focus from the frame to the main page.

Let’s take a simple example:

Launch https://the-internet.herokuapp.com/iframe. We have to copy the text located under the left bottom iFrame.

Code snippet is attached below.

    import org.openqa.selenium.By;
    import org.openqa.selenium.WebDriver;
    import org.openqa.selenium.WebElement;
    import org.openqa.selenium.chrome.ChromeDriver;
    import java.util.concurrent.TimeUnit;
    public class iFrameTest{
      public static void main(String[] args) {
         System.setProperty("webdriver.chrome.driver", "C:\Users\kailashpathak\Desktop\Java\chromedriver.exe");
         WebDriver driver = new ChromeDriver();
         driver.get("https://the-internet.herokuapp.com/frames");
         driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
         // Click in Nested link
         driver.findElement(By.partialLinkText("Nested")).click();
         // In below line we are switching to the frame in left bottom side
         driver.switchTo().frame("frame-bottom");
         WebElement text = driver.findElement(By.cssSelector("body"));
         System.out.println("Frame text: " +text.getText());
         driver.close();
      }
    }

Cypress:

Cypress does not handle iFrame directly; we need to install the plugin and use the plugin to perform actions on elements inside the iframe. We can install the plugin and then use the custom commands.

  npm install -D cypress-iframe

Notice below that it is represented by the tag ‘iframe’ having the ‘class’ mentioned below.

The below code works with elements inside an iFrame.

    import 'cypress-iframe'
    describe('ifrane example', function () {
      // test case
      it('iframe Test cases', function (){
         // launch the URL
         cy.visit("https://jqueryui.com/draggable/");
         // frame is loading in below line
         cy.frameLoaded('.demo-frame');
         //shifting the focus
         cy.iframe().find("#draggable").then(function(t){
            const frmtxt = t.text()
            //assertion to verify text
            expect(frmtxt).to.contains('Drag me around');
            cy.log(frmtxt);
         })
      });
    });

Check this out: SHA384 hash generator generates a SHA384 hash (SHA384 encoded) containing 96 hexadecimal digits. This can be used as a secure password or as a key to protecting essential data, such as personal information, money transactions, and much more.

Handling API Requests

Testing doesn’t mean to do verification of elements in UI only, but we also have to verify data that is bound with these elements from the API side as well.

API (Application Programming Interface) is the middle layer between the presentation and the database layer. APIs play a very important role in communication between one software application to another. Because of this reason, testing of API’s has become very important nowadays. Here we are comparing Playwright vs Selenium vs Cypress to see how we can do API testing using these frameworks.

Playwright:

Playwright can be used to get access to the REST API of your application. Below are examples of how we can automate the API request using the methods (GET, POST, PUT, and DELETE)

GET Method

   // @ts-check
    const { test, expect } = require("@playwright/test");
    test.describe("API Testing with Playwright", () => {
     const baseurl = "https://reqres.in/api";

     test("GET API Request with -- Valid 200 Response ", async ({ request }) => {
       const response = await request.get(`${baseurl}/users/2`);
       expect(response.status()).toBe(200);
     });
    });

POST Method

   // @ts-check
    const { test, expect } = require("@playwright/test");
    test.describe("API Testing with Playwright", () => {
     const baseurl = "https://reqres.in/api";
     test("POST API Request with -- Valid 201 Response ", async ({ request }) => {
       const response = await request.post(`${baseurl}/users/2`, {
         data: {
           id: 123,
         },
       });
       const responseBody = JSON.parse(await response.text());
       expect(responseBody.id).toBe(123);
       expect(response.status()).toBe(201);
     });
    });

PUT Method

    // @ts-check
    const { test, expect } = require("@playwright/test");
    test.describe("API Testing with Playwright", () => {
     const baseurl = "https://reqres.in/api";
     test("PUT API Request with -- Valid 201 Response ", async ({ request }) => {
       const response = await request.put(`${baseurl}/users/2`, {
         data: {
           id: 245,
         },
       });
       const responseBody = JSON.parse(await response.text());
       expect(responseBody.id).toBe(245);
       expect(response.status()).toBe(200);
     });
    });

DELETE Method

    // @ts-check
    const { test, expect } = require("@playwright/test");
    test.describe("API Testing with Playwright", () => {
     const baseurl = "https://reqres.in/api";
     test("DELETE API Request with -- Valid 201 Response ", async ({
       request,
     }) => {
       const response = await request.delete(`${baseurl}/users/2`, {});
       expect(response.status()).toBe(204);
     });
    });

Selenium:

Selenium is primarily a browser automation tool and is not designed for API testing. It allows you to interact with web browsers and automate user interactions on a website or web application. But, Selenium can’t be used to directly test the functionality of an API, as it doesn’t provide any functionality to send HTTP requests and assert on the API’s response.

However, LambdaTest can be used to perform API automation using Selenium. LambdaTest is a cloud-based platform that provides a Selenium Grid that allows you to perform Selenium automation testing on various browsers, operating systems, and devices.

One way to use Selenium to test an API using LambdaTest is by launching a browser on LambdaTest’s Selenium grid, navigating to the API endpoint URL, and then using Selenium to interact with the API by sending HTTP requests and asserting on the response. This is similar to how you would test a website or web application.

Cypress:

Using Cypress, we can do API automation. To make a Cypress API call, Cypress has provided the command cy.request(). GET, POST, PUT, and DELETE are some methods that are part of the API (Application Programming Interface) testing, which can be performed by Cypress.

Below are the example of different methods:

GET Method

To perform a GET operation, we shall make an HTTP request with the cy.request() and pass two parameters in cy.request() Method name and URL.

    it("GET API testing Using Cypress", () => {
     cy.request("GET", "https://reqres.in/api/users?page=2").should((response) => {
       expect(response.status).to.eq(200);
     });
    });

POST Method

To perform a POST operation, we shall make an HTTP request with the cy.request() and pass three parameters in cy.request() Method name and URL and body.

   it("POST API testing Using Cypress", () => {
     cy.request("POST", "https://reqres.in/api/users", {
       name: "morpheus",
       job: "leader",
     }).should((response) => {
       expect(response.status).to.eq(201);
     });
    });

PUT Method

To perform a PUT operation, we shall make an HTTP request with the cy.request() and pass three parameters in cy.request() Method name and URL and body.

    it("PUT API testing Using Cypress", () => {
     cy.request("PUT", "https://reqres.in/api/users/2", {
       name: "morpheus",
       job: "zion resident",
     }).should((response) => {
       expect(response.status).to.eq(200);
     });
    });

DELETE Method

To perform a DELETE operation, we shall make an HTTP request with the cy.request() and pass two parameters in cy.request() Method name and URL.

   it("DELETE API testing Using Cypress", () => {
     cy.request("DELETE", "https://reqres.in/api/users/2").should((response) => {
       expect(response.status).to.eq(204);
     });
    });

Check this out: SHA256 hash function generator generates a SHA256 hash (SHA256 encoded) containing 64 hexadecimal digits. This can be used as a secure password or as a key to protecting essential data, such as personal information, money transactions, and much more.

Community support

Selenium is an open-source suite of tools for automated web testing, and it has a large and active community of users and developers. There are several ways that community members can get support and help with Selenium. Here we are comparing Playwright vs Selenium vs Cypress to see their community support.

Playwright:

Playwright is a new player in the market and has a smaller but growing set of community resources. There are numerous resources available to help users get started with Playwright and troubleshoot any issues they may encounter. The Playwright team has great documentation and an active presence on GitHub, where users can submit bug reports and feature requests, and contribute to the development of the tool. The team is also responsive to questions and feedback from the community.

In addition to the official channels, there are a number of community-run forums and resources where users can get help with Playwright. These include Stack Overflow, Reddit, and the Playwright Gitter chat.

Selenium:

There are several ways that community members can get support and help with Selenium:

Selenium documentation: It is a comprehensive resource that covers all aspects of using Selenium. It includes tutorials, a reference guide, and information on installing and configuring Selenium.
Selenium forums: The Selenium forums are a good place to ask questions and get help with Selenium. There are separate forums for different programming languages, as well as a general discussion forum.
Selenium Slack channel: The Selenium Slack channel is an active community of Selenium users and developers who are available to answer questions and provide support. To join the Selenium Slack channel, you will need to request an invite by filling out a form on the Selenium website.
Stack Overflow: Stack Overflow is a popular question-and-answer website for programmers, and it has a large number of questions and answers related to Selenium. You can search for answers to your questions or ask a new question and get help from the community.

Cypress:

Cypress has a growing Community, and their documentation is excellent. In addition, there are numerous unofficial forums and communities where Cypress users can connect and share their experiences with the tool.

In addition to online forums, the Cypress community also provides support through various resources and documentation. The Cypress website features detailed documentation on installing and using the tool, a comprehensive API reference, and a library of example projects. There are also many blog posts, tutorials, and video resources available online that guide on using Cypress for various testing tasks.

Check this out: An SHA-1 Hash calculator is a tool that creates a 160-bit (20-byte) hash value for a specified input, generally referred to as a “message” or “data.”

Comparison Table: Playwright vs Selenium vs Cypress

	PLAYWRIGHT	SELENIUM	CYPRESS
Language Support	JavaScript Java, C#, Python, Ruby	JavaScript Java, C#, Python, Ruby	JavaScript/TypeScript
Browser Support	Chrome, Edge, Firefox, Safari	Chrome, Edge, Firefox, Safari	Chrome, Edge, Firefox, Safari
Framework Support	Jest/Jasmine, AVA, Mocha, and Vitest	Mocha, Jest/Jasmine,, TestNG, JUnit, Cucumber and NUnit	Supports Mocha, Jest/Jasmine, Cucumber
Continuous Integration	Can be easily integrated with continuous integration tools like Jenkins	Can be easily integrated with continuous integration tools like Jenkins	Can be easily integrated with continuous integration tools like Jenkins
Ease of use	Playwright has a user-friendly interface and requires minimal setup	Selenium requires more setup and has a steeper learning curve	Cypress has a user-friendly interface and requires minimal setup
Test Writing Experience	Intuitive	Moderate	Intuitive
DOM manipulation	Easy	Moderate	Easy
Community Support	Growing community	Large and active community with good documentation and support resources	Active community with good documentation and support resources
Support for headless mode	YES	YES	YES
Parallel Execution	Supports parallel execution	Supports parallel execution	Supports parallel execution using CI/CD tool
Built-in network traffic control	YES	NO	YES
Setup complexity	Easy Setup	Requires some effort to build the framework	Easy Setup
Iframe Support	YES	YES	Iframe support through plugin e.g. cypress-iframe
Driver	No driver required	Each browser requires its driver	No need of driver bindings
Multi Tab Support	YES	NO	YES
Drag & Drop Support	YES	YES	YES
Test Assertions Libraries	Mocha, Chai	PyUnit, JUnit, TestNG almost any language-specific test framework can be adapted.	Mocha, Chai
Inbuilt reports	YES	NO	Default Reporter is Spec, Customizable for other supported reporters
Cross-Domain Support	YES	YES	YES
Debug features	Playwright has built-in debugging tools and a time-traveling feature for easy debugging	Selenium does not have built-in debugging tools	Cypress has built-in debugging tools and a time-traveling feature for easy debugging
Automatic Waiting	YES	NO	YES
Dashboard	NO	NO	Provided as Premium/Paid Feature
Community Support	Good	Very Good as the user base is more.	Good
Built-in Screenshot, VIDEO feature	YES	No built-in screenshot feature. Customization is required to add this feature.	YES
Pricing	Free for open-source projects, paid for commercial use	Free for all use cases	Free for open-source projects, paid for commercial use

Obtain certifications in test automation frameworks like Playwright, Selenium, and Cypress that enhance your resume and increase your chances of obtaining a highly sought-after position. Obtain this certification as tangible proof of your expertise in test automation on LambdaTest’s cloud infrastructure, displaying mastery of advanced knowledge and skills.

Check this out: The SHA512 Hash Calculator lets you generate the SHA512 hash of any string.

Wrapping up

In this blog on Playwright vs Selenium vs Cypress, we have learned how tools like Playwright, Selenium, and Cypress are designed to automate web browsers for testing. While they each have distinct architectures, user bases, and objectives, it is up to testing teams to decide which tool is the most appropriate for their project and skill set. With the varying features and capabilities when comparing Playwright vs Selenium vs Cypress, it is essential to carefully consider the needs of the project and the team’s strengths before making a decision.

How To Run Cypress Tests In Azure DevOps Pipeline

Kailash Pathak — Wed, 28 Dec 2022 14:58:08 +0000

When software developers took years to create and introduce new products to the market is long gone. Users (or consumers) today are more eager to use their favorite applications with the latest bells and whistles. However, users today don’t have the patience to work around bugs, errors, and design flaws. People have less self-control, and if your product or application doesn’t make life easier for users, they’ll leave for a better solution.

Before the advent of DevOps, software companies used the conventional Waterfall model, which was effective for many projects like CRM and inventory management. However, it had several shortcomings. DevOps completely overpowered the traditional waterfall model.

Development teams in product organizations are constantly releasing updates, patches, bug fixes, and new features. Before rolling out the updates to all end users, operations teams have their hands full to ensure the new code functions properly. Users dislike downtime and additional errors, which can occur if the rollout process isn’t managed effectively.

In DevOps, code is reviewed and deployed much more quickly due to the collaboration between the development and operations teams. As a result, suggestions for new features and bug fixes based on user data get continuously incorporated into the development cycle. The journey each new piece of code takes, from planning to deployment to monitoring, is known as the DevOps pipeline. Every software development company needs a strong DevOps pipeline to meet customer demands and specifications.

Azure, AWS, GCP, Oracle Cloud Services, and many other cloud service providers have integrations with several open-source and enterprise automated testing tools. Cypress is the most commonly used framework that has integrations with all major cloud platforms. There are also testing platforms like LambdaTest, a cloud SaaS platform for Cypress testing that we can integrate with Azure DevOps.

Cypress Trends on GitHub

As per the Cypress GitHub repository, Cypress continues to gain popularity with:

Stars: 39.5k
Forks: 2.5k
Used By: 599k
Releases: 282
Contributors: 400

This Cypress tutorial on how to run Cypress tests in Azure DevOps aims at getting people started with running automation testing on Microsoft’s Azure. We will deep dive into the essentials of Azure DevOps along with running Cypress automated tests with Azure Pipeline.

To make this tutorial more interesting, I have broken it down into different parts. First, I will explain DevOps, the Components/Stages of DevOps then how we Can Set Up Cypress and run Cypress tests in Azure DevOps pipeline. Finally, integrate Azure pipelines with LambdaTest and run Cypress test cases.

Check this out: Selenium Tutorial: A Complete Guide on Selenium Automation Testing

What is DevOps Pipeline?

DevOps is a software development methodology that connects the Development and Operations sides of an application. It bridges the gap between developers and maintainers by introducing collective responsibility practices. Traditionally, there was a barrier between these teams, and software packages were metaphorically pushed past the wall. But with DevOps processes, that barrier no longer exists.

A pipeline in software development consists of a set of tools, flows, and automated processes that enable the team to leverage technologies to build and deploy the application/software.

The process of building, testing, and deploying code is known as continuous integration & continuous deployment, or CI/CD. Automating this process can minimize human error and maintain a consistent process for how software is released.

You can develop, test, and continuously deploy new code by creating an effective DevOps pipeline. Building an efficient DevOps pipeline enables organizations to develop, test, and continuously deploy new code rapidly.

One of the main goals of a DevOps pipeline is to automate the software delivery process, thus eliminating the need for manual changes at every step of the pipeline.

Manual work is time-consuming and risks human error, which often delays deployments. Switching from manual to automated changes results in fewer errors and allows developers to release higher-quality code faster than ever.

LambdaTest lets you integrate and run Cypress tests in Azure DevOps Pipelines using an extension that connects the CI server to LambdaTest’s cloud Cypress Grid.

Components of a DevOps Pipeline

In order to run Cypress tests in Azure DevOps Pipeline, let’s discuss the components of a DevOps pipeline.

There are several different approaches and tools that organizations normally use to create a customized DevOps pipeline. Common pipeline components enable continuous delivery by ensuring that code flows smoothly from one stage to the next, automating the entire process and reducing manual work.

A well-constructed pipeline comprises tools that automate processes and permit continuous iteration. Which are:

Continuous Integration

Continuous Integration (CI) means multiple integrations every day. In the past, when the team didn’t have the continuous integration concept, we had to wait for a long time to reflect the actual code into production. Since code is integrated very late, the chance of code conflict is increased due to this delay.

Contrary to the previous methodology, CI encourages developers to submit their code regularly. As a result, they can identify bugs more quickly and spend less time fixing them.

Continuous Integration (CI) is a development practice requiring developers and quality assurance personnel to commit code changes to a shared repository (e.g., GIT repository) several times a day. When we push the code, the CI tool pulls the code from the shared repository and makes the build.

The CI tool builds the code in addition to performing other background tasks like code review, integration testing, and running unit test cases. CI has some best practices in modern DevOps — which detects and notifies developers what has happened. GitHub users can implement CI through GitHub Actions. Azure DevOps users can use Azure Pipelines.

Continuous Delivery

Continuous Delivery (CD) is nothing more than the evolution /or next step of CI. It is about speeding up the release process by encouraging developers to release code for user acceptance testing in the test environment. Once the build is successful, the code is deployed to the test server for user acceptance or end-user testing.

Continuous Delivery (CD) has great advantages. Let’s look at some of the benefits offered by CD. Before CD, developers used to take much longer to locate the issue if there was an error in the build. With CD in place, it became easy to track which particular commit is causing the failure.

The more frequently you can deploy code updates, the better off you’ll be able to use continuous deployment. The workflow determines the release frequency, typically daily, weekly, or monthly. Compared to releasing all changes at once, releasing code in smaller chunks makes it simpler to fix bugs. By doing this, bottlenecks and merge conflicts are prevented, and the integration pipeline continues to flow steadily and continuously.

Continuous Deployment

Continuous Deployment is the next step in automating the software development lifecycle after continuous delivery. Continuous Delivery and Continuous Deployment are similar in many ways, yet there are subtle differences. In continuous delivery, code is periodically committed to the staging branch for user acceptance testing. While continuous deployment allows development teams to deploy software, features, and code updates manually, continuous deployment is about automating the entire release cycle.

In the continuous deployment phase, code updates are automatically released to the targeted users without manual intervention. If something goes wrong, you can roll back the changes without causing the application to stop working. To fully realize the potential of continuous deployment, robust automation testing frameworks like Selenium, Cypress, etc., must be in place to ensure that the new code is truly bug-free and can be deployed to production without delays.

Continuous Testing

Continuous testing is another part of the DevOps pipeline. Using continuous testing, you can run automated tests for the code integrations gathered during the continuous integration phase. To find problems before they affect the production environment, continuous testing involves running tests as frequently as possible at each stage of the development process. Rapid evaluation of the business risks associated with particular release candidates in the delivery pipeline is made possible by implementing a continuous testing strategy.

Functional and non-functional testing should both be included in the testing scope. This entails carrying out the unit, system, and integration tests as well as tests that focus on an application’s security and performance along with the server infrastructure.

Continuous testing encompasses a broader understanding of quality control, including risk assessment and internal policy compliance. Some types of testing that can be automated include end-to-end testing, regression testing, functional tests, integration tests, and performance tests that run automatically as soon as the code is integrated.

Every DevOps cloud platform has some stages. Below are some stages that DevOps pipelines normally have.

Run End-to-End Cypress tests on the cloud grid. Try LambdaTest Now!

Check this out: 30 Top tools for Automation Testing In 2022

Stages of a DevOps Pipeline

There are no strict guidelines for how you should structure the pipeline. DevOps teams add or remove certain phases depending on their specific workflows. Almost all pipelines consist of four core phases: Development, Build, Test, and Deploy.

You can extend the setup by adding two more stages — plan and monitor — as they are also ubiquitous in professional DevOps environments.

Plan

Planning your project, technology, environment, structure, and architecture creates a roadmap for successfully achieving your project goals. In the planning phase, the entire workflow is planned before developers start coding. Product managers and project managers are crucial during this stage. It is their responsibility to develop a development roadmap that will serve as a guide for the entire team.

The work is further broken down into a list of tasks after gathering feedback and relevant information from stakeholders and users. Teams can produce results more quickly, address issues immediately, and adjust to unforeseen changes more readily by breaking the project into smaller, more manageable pieces. In a DevOps environment, teams work in sprints — a shorter time (usually two weeks) during which individual team members work on their assigned tasks.

Develop

Development phase is when developers start writing code. Developers install the appropriate IDEs, code editors, and other technologies on their local computers depending on the programming language to achieve maximum productivity.

Developers submit a pull request to the shared source repository when they are prepared to submit their code. Once the initial pull request has been approved, team members can manually review the recently submitted code and merge it with the branch.

Build

A compilation process is used to extract the source code from the repository, link it to libraries, modules, and dependencies, and create an executable. A DevOps pipeline’s build phase is crucial because it enables developers to find code errors before they get into the pipeline, resulting in a major catastrophe.

Newly written code is merged with the shared repository, and developers run a series of automated tests. The pull request typically starts an automated process that builds the code into an executable or deployable package. Some programming languages do not need to be compiled.

For example, applications written in Java and C must be compiled to run, while PHP and Python do not. Build fails if there are issues with the code and the developer is informed of the issues. To ensure that only bug-free code gets into the pipeline, developers repeat this procedure each time they push code to the shared repository.

Test

The testing stage begins after a successful build. Once ready, the build is then deployed to the test environment where you can perform several types of testing like user acceptance test, security test, integration testing, performance testing, end-to-end testing, and cross browser testing.

Deploy

When the build reaches the deployment stage, the software is ready to be moved to production. When only minor changes to the code are required, an automated deployment method is used. To see how the newly added code functions, the build is first deployed to a production-like environment if the application has been significantly reworked.

Blue/green deployment is a common method of deployment for continuous delivery, where two environments are configured identically — one environment serves end users, while the other is ready for new code to deploy and undergo testing, such as performance testing, end to end testing, and cross browser testing

Monitor

Operations teams put in a lot of effort to monitor infrastructure, systems continuously, and applications during this last stage of the DevOps pipeline to make sure everything is operating as it should. To find performance problems, they gather important data from logs, analytics, monitoring systems, and user feedback.

The DevOps pipeline is more effective using the feedback gathered during the Monitor phase. After each release cycle, optimizing the pipeline is a good idea to eliminate any potential bottlenecks or other problems that might reduce productivity.

Now we know what scenario we will cover in this blog on how to run Cypress tests in Azure DevOps. But before running our scenario, we need to set up and create Cypress code using the below-mentioned steps.

Check this out: Online Automation Testing Platform- Accelerate your release velocity with blazing fast test automation cloud

Demonstration: Setup Cypress tests in Azure DevOps pipeline

To explain how we can set up the Azure pipeline for Cypress test cases, I will be testing a typical e-commerce site https://ecommerce-playground.lambdatest.io/.

Project Setup

You can follow the steps mentioned below to create a new Cypress project:

Step 1: Create a folder and generate package.json.

Create a project by the name Cypress_Lambdatest.
Create a package.json file using the npm init command in the terminal.

**Step 2: **Install Cypress.

Run this command in the newly created folder to install Cypress.

npm install cypress —save-dev

yarn add cypress --dev

This will install Cypress locally as a dev dependency for your project.

Cypress version 9.2.0 is reflected once this is installed, as seen below. The most recent version of Cypress is 10.11.0

      {
       "name": "cypress_lambdatest",
       "version": "1.0.0",
       "description": "",
       "main": "index.js",
       "scripts": {
         "cy:report": "cypress run"
       },
       "author": "Kailash Pathak",
       "license": "ISC",
       "devDependencies": {
         "cypress": "^9.2.0"
       }
      }

Shown below is the default folder structure of Cypress. You can create test cases under the folder “integration”

Under the integration folder named “cypress_lambdatest,” let’s create a new folder.

Under the folder lambdatest, create the first spec with the name login_searchproduct.spec.js. Second spec with the name ScrollAnd_ClickProduct.spec.js.

Implementation (Test Scenario — 1)

To demonstrate the usage of Cypress, we will first demonstrate the following test scenario.

Test Scenario:

Open the URL https://ecommerce-playground.lambdatest.io/index.php?route=account/login.
Enter your email address.
Enter the password.
Click on the Login button.
Search for the product “VAIO.”
Verify the correct product is searched.
Logs out from the application.

Create a login_searchproduct.spec.js file with the script below. This covers login into the application and searching for the product. After the search, verify the correct product should be displayed.

    /// <reference types="cypress" />
    it("Open the Url", () => {
     cy.visit(
       "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
     );
    });
    it("Login into the application", () => {
     cy.get('[id="input-email"]').type("lambdatest@yopmail.com");
     cy.get('[id="input-password"]').type("lambdatest");
     cy.get('[type="submit"]').eq(0).click();
    });
    it("Search the Product", () => {
     cy.get('[name="search"]').eq(0).type("VAIO");
     cy.get('[type="submit"]').eq(0).click();
    });
    it("Verify Product after search ", () => {
     cy.contains("Sony VAIO");
    });

Code Walkthrough:

In the above code snippet, we have opened the target URL using cy.visit(), and Second, it() block is used to log in to the application by entering email and password.

In the third, it() block is used for searching for the product, and the last it() block is used for searching for the product.

In the below screenshot, we can see how we can inspect the element. We have located element by id for the email field

   cy.get(‘[id=”input-email”]’).type(“lambdatest@yopmail.com”);

Check this out: Online Safari For Windows. Say No To Safari VM! Perform Cross Browser Compatibility Testing On All Safari Browser Versions Across Real Browsers And Operating Systems.

Implementation (Test Scenario — 2)

Test Scenario:

Open the URL https://ecommerce-playground.lambdatest.io/index.php?route=account/login.
Enter your email address.
Enter the password.
Click on the Login button.
Now, Scroll to the bottom of the application.
Click on a particular product.

    /// <reference types="cypress" />
    it("Open the Url", () => {
     cy.visit(
       "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
     );
    });
    it("Login into the application", () => {
     cy.get('[id="input-email"]').type("lambdatest@yopmail.com");
     cy.get('[id="input-password"]').type("lambdatest");
     cy.get('[type="submit"]').eq(0).click();
    });
    it("Click on Lambdatest Logo", () => {
     cy.get('[title="Poco Electro"]').click();
     cy.wait(5000);
    });
    it("Scroll to the bottom and Click on product 'Nikon D300' ", () => {
     cy.get('[title="Nikon D300"]').eq(0).scrollIntoView().click();
    });

Code Walkthrough:

In the above code snippet, first, we open the e-commerce site URL using cy.visit(). Second, it() block is used for login into the application by entering your email and password.

In the third, it() block, you will be redirected to the home page after clicking on LambdaTest Logo.

And In the Final it() block, you will scroll to the bottom of the page and click on the particular product.

The Cypress chain starts with cy.[command], where what is yielded by the command establishes what other commands can be called next (chained). cy.get() *or *cy.contains() methods yield a DOM element. This allows further commands to be chained onto them (assuming they expect a DOM subject), like .click() or even cy.contains() again.

In the below screenshot, we can see how we can inspect the element. We have located elements by type for the Login button.

    cy.get(‘[type=”submit”]’).eq(0).click();

Check this out: Online Web Testing Platform. Check your websites and web applications in all major browsers with LambdaTest.

How to run Cypress tests in Azure DevOps pipeline?

Traditionally in the software testing life cycle, once QA creates the test cases, the QA has to wait for the build to deploy in the appropriate environment to test the functionality and to give the final sign-off of the build because, at that time, there was no concept of auto-deployment of the code. However, now there are many cloud computing platforms. One of the most popular is the Azure pipeline for building the code and deployment at regular intervals as code is pushed.

Azure Pipeline helps us to deploy code automatically in prod and test fastly. As the team pushes code within a few seconds pipeline is triggered automatically, and code deployment is started. Azure pipeline helps us ensure consistent and quality code readily available to users.

We can use the Azure pipeline with Cypress for code deployment and execute the test cases.

We have created a Cypress spec file for the scenario. The next step is to set up the Azure pipeline to execute our test cases using Cypress.

Pre-requisites

Let’s look at the prerequisites to run Cypress tests in Azure DevOps Pipeline.

Cypress code has already been pushed into the GitHub repository.
Azure free account already created through URL.
User is already logged into Azure DevOps.

Step 1: Create the pipeline.

Click on Pipelines from the left navigation and then click on New pipeline.

2- Click on New pipeline.

3- After clicking on the New pipeline, the below page is open.

Step 2: Select Classic editor.

Click on Use the classic editor to create a pipeline without YAML from the above screen. The classic editor walks you through using a wizard-like process that guides you as you create your build.

Step 3: Select the repository.

Click on the GitHub icon to select the repository.

2- Select the repository and branch name from the existing repository.

3- Click on Continue, the below page is open.

Step 4: Select Empty Job.

Select the template as an Empty job.

2- After clicking on “Empty job” on the next screen, we can see under the Tasks **tab three options: **Pipeline, Get Source, and Agent job. By default, the pipeline is selected.

On the right side:

Enter the Name **of the pipeline, e.g., **Cypress Lambdatest Project.
In the Agent pool: Select ‘Azure Pipelines’ from the drop-down.
In the Agent Specification: Select OS ‘window-latest’ (Test cases are run in this OS).

Step 5: Configure Get Source under the Task tab.

Under Get sources, make sure the correct repository and build are selected.

Step 6: Configure Agent Job under the Task tab.

In the Agent Job section under the **Tasks **tab, enter the following information.

Enter the Display Name of the pipeline, e.g., Cypress Lambdatest.
In the Agent pool: Select ‘Azure Pipelines’ from the drop-down.
In the Agent Specification: Select Agent ‘window-latest’ (test cases are run in this agent).

Step 7: Add the npm package.

Now Click on the (+) icon against the Project, search for “npm” and click on the Add button.

After adding “npm,” from the left side, click on npm install (See below screenshot). Enter/Select the below data (on the right side) to install the Cypress and other dependencies.

Enter the Display name, e.g., npm install.
In the Command: Enter ‘install’.
In the Control Options: Select Check Box ‘Enabled’ and Check Box ‘Continue on error’.

Step 8: Add npm package to Run Cypress Tests in Azure DevOps Pipeline.

Now Click on the (+) icon, search for “npm” again, and click on the Add button.
Click on npm install from the left side (See below screenshot). On the Right side, enter /select the below data to install Cypress and other dependencies.

Enter the Display name, e.g., Run Cypress Lambdatest.
In the Command: Enter ‘custom’.
In the Command and arguments: Enter run cy:report.

Step 9: Click Save & queue.

Now Click on ‘Save & queue’.

As the user clicks on Save & queue, this will open a dialogue box as below. Select the agent pool, agent, and the branch from which Azure DevOps needs to execute the build

Step 10: Click Save and run.

As we click on Save and run, the Job starts executing.

In the first step, the job is initialized.

2- In the second step, code is pulled from the repository. In this case, the code pulls from .github.

3- In the third step, the npm command runs to install the package.

4- In the fourth step, the Cypress test case starts executing. In the below screenshot, we can see using the command cy:report (Which we have given in package.json) test case starts executing.

5- In the fifth and sixth steps, we have to purge the repository, and the job is finished.

Check this out: Accelerate Delivery With Mobile App Test Cloud- Test your native mobile applications using LambdaTest’s online real device cloud and virtual testing platform of emulators and simulators.

How to run Cypress tests in Azure DevOps pipeline on cloud Cypress Grid?

Azure Pipelines is a CI server that automates the build and deploys process of your native web apps. There is an easy way to integrate LambdaTest to run Cypress tests in Azure DevOps pipelines.

LambdaTest is a cloud-based cross browser testing platform that lets you test your website on an online browser farm of 3,000+ browsers, operating systems, and device emulators. It can be used to perform manual web testing and automated browser testing.

Using Cypress automation tools like LambdaTest, you can execute & analyze Cypress test scripts online as a part of the build process. It enables continuous testing, build, and deployment of iterative code changes. Best CI/CD tools help in catching failures ahead of the production stage and mitigate them as they occur. Perform Cypress UI testing on 40+ browsers and browser versions, including headless ones.

Check this out: Selenium Testing Automation Cloud- Test on Selenium Grid Cloud of 3000+ Desktop & Mobile Browsers.

You can also Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around automated browser testing, Selenium testing, CI/CD, and more.

To simplify, we have ported the test scenarios mentioned in the earlier section of this blog on how to run Cypress tests in Azure DevOps pipeline so that tests run parallel on LambdaTest Cypress Grid.

Cut test execution time with Cypress Parallel testing. Try LambdaTest Now!

Before getting started with Cypress and integrating the Azure pipeline with LambdaTest, we should have the information below information:

An Azure CI account.
A Git or GitHub repository.
LambdaTest Authentication Credentials that can be accessed from the LambdaTest profile page.

There are steps to integrate Azure pipelines with LambdaTest and run Cypress tests in Azure DevOps pipeline, as explained below.

Step 1: Create a project.

The first step is to create the project. Click on “New project” and fill in the required field.

Step 2: Create the pipeline.

Once the project is created the next step is to create the pipeline by clicking on Create Pipeline.

Step 3: Select GitHub.

If you have your code repository in GitHub, then select the option for GitHub from the values.

Step 4: Create a YAML file.

Once you choose an option for code repository, you will be asked to log in. Once you log in, you need to choose the specific repository. Here, the repository will pick the azure-pipelines.yml file.

FileName: azure-pipelines.yml

    # Node.js
    # Build a general Node.js project with npm.
    # Add steps that analyze code, save build artifacts, deploy, and more:
    # https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

    trigger:
     - master

    pool:
     vmImage: ubuntu-latest
    variables:
     LT_USERNAME: "<LT_USERNAME>"
     LT_ACCESS_KEY: "<LT_ACCESS_KEY>"

    steps:
     - task: NodeTool@0
       inputs:
         versionSpec: "10.x"
       displayName: "Install Node.js"

     - script: |
         npm install
         npm install -g lambdatest-cypress-cli
         npm run cy:report
       displayName: "npm install and Run Cypress test case in lambdatest cloud"

Yaml file explanation:

trigger: Under trigger, You can specify the full name of the branch (for example, master).
pool: Under the pool, we can mention the name of the agent where we want to run your test case.
variable: Under variable, you can add LambdaTest credential.
steps: Under steps, you can add various tasks here. We added a task to install the node with the specific version.
script: Under the script, you can mention the package you want to install using npm and run the test cases using npm.

File: lambdatest-config.json:

In the lambdatest-config file, we can provide the credential, run_setting, and browser with the version in which we want to run our test cases.

   {
     "lambdatest_auth": {
       "username": "<username>",
       "access_key": "<access_key>"
     },
     "browsers": [
       {
         "browser": "Chrome",
         "platform": "Windows 10",
         "versions": ["latest"]
       },
       {
         "browser": "Chrome",
         "platform": "Windows 10",
         "versions": ["latest-1"]
       },
       {
         "browser": "Firefox",
         "platform": "Windows 10",
         "versions": ["latest"]
       },
       {
         "browser": "Firefox",
         "platform": "Windows 10",
         "versions": ["latest-1"]
       }
     ],
     "run_settings": {
       "cypress_config_file": "cypress.json",
       "build_name": "build-name",
       "parallels": 4,
       "specs": "./cypress/integration/lambdatest/*.spec.js",
       "ignore_files": "",
       "feature_file_suppport": false,
       "network": false,
       "headless": false,
       "reporter_config_file": "",
       "npm_dependencies": {
         "cypress": "9.2.0"
       }
     },
     "tunnel_settings": {
       "tunnel": false,
       "tunnel_name": null
     }
    }

Step 5: Run Test cases.

We are using Cypress version 9.2.0 for testing our scenarios. At the time of writing this blog on how to run Cypress tests in Azure DevOps pipeline, the latest version of Cypress was 10.11.0 when writing this blog.

As the build in Azure Pipeline starts, the first step job is initialized.

In the second step, code is pulled from the repository. In this case, code pulled from .github.

In the third step, the node is installed.

In the fourth step, npm install various packages, and finally, the cypress test cases start executing.

In the screenshot below, we can see that the command cy:report (Which we have given in package.json) test case starts executing in the LambdaTest platform.

Execution:

In the below screen, you can see test cases start running in *four browsers **parallelly (Browser details given above **in File: lambdatest-config.json)*.

In the below screenshot, we can see the test cases are passed in Firefox and in Chrome browser, test cases are running.

In the below screenshot, we can see that both test cases are passed in different browsers.

Here are the logs that are generated when the test cases are run successfully.

In the below screenshot, we can see that VIDEO products are loading.

In the below screenshot, we can see after scrolling to the bottom product is clicked.

If you’re a developer or a tester, the Cypress 101 certification will help you understand the fundamentals of Cypress end to end testing and prepare you to write tests faster, with greater confidence and clarity.

Check this out: How To Use ios emulators for PC

Wrapping Up

I hope this gives you a great starting point for building your first Azure DevOps pipeline. You will understand how we can run Cypress tests in Azure DevOps Pipelines on cloud-based platforms like LambdaTest.

Cypress End to End Testing Tutorial: A Detailed Guide

Kailash Pathak — Tue, 20 Dec 2022 12:01:17 +0000

Software applications nowadays have become increasingly complex, and maximizing test coverage is one of the key aspects for every testing team. Testers globally rely upon different testing types using testing tools and frameworks. But there is an urgent need to test software systems (along with all their sub-systems) from beginning to end.

End to End (E2E) testing permits testing teams to drive quality throughout the pipeline by replicating critical real-user scenarios. In addition, it enables teams to validate software systems and their sub-systems for data integrity. End to End testing isn’t easy.

Cypress makes setting up, writing, running, and debugging tests easy. We usually neglect End to End testing because it requires a large part of the effort to implement. Performing End to End tests using the manual approach can be a tedious and error-prone task. With Cypress visual regression testing, you can verify the graphical component of a web application.

Cypress is one of the options when it comes to End to End testing. With Cypress, you don’t need to install ten different things to set up your test suite. In minutes, you can start writing your test cases with the help of Cypress API. Cypress runs test cases inside the browser, which makes it different from other frameworks (e.g., Selenium). Cypress uses Chai, which is a popular assertion library. It also uses Mocha, a framework that provides the syntax for testing in a Behavior-Driven Development (BDD) style.

In this Cypress tutorial on End to End testing, we will deep dive into performing Cypress End to End testing on a local Cypress grid and over a cloud Cypress grid like LambdaTest.

So, let’s get started!

Why End to End Testing?

Most of the End to End application testing used to be performed manually, with a QA team understanding the requirements, making test cases, executing the test cases, and recording the results. In modern software development, automation has become the foundational part of testing.

The software can and must be tested on many tiers. When you design a system, you begin with a small piece of software, for which unit testing is sufficient. However, testing software at the unit level isn’t enough, and it does not guarantee that these small units should work perfectly when combined.

This is where integration testing comes into the picture. In integration tests, two or more components are used together in a test, and the result is validated. Though all these tests run perfectly fine, integration testing can’t guarantee that the system will work as expected. This is where End to End testing comes into the picture.

End to End testing is closest to real user testing. Cypress is one of the best automation testing frameworks for E2E testing because Cypress runs the application in the browser, thereby providing the experience as if the application is running inside the actual browser. The closer the test is to mimic the user, the more likely it will locate issues that the user(s) might experience.

To understand End to End testing, let’s deep dive into the test automation pyramid introduced by Mike Cohn. It makes testing efficient. All levels of testing mentioned in this pyramid we usually do when running automated Cypress testing.

In automation, we start by automation of lower units; once they are ready, we write our integration automation scripts. Finally, once the integration test is done, we do End to End testing to ensure our script works correctly together, including third-party code.

Layers of the Testing Pyramid

Test pyramid is an empirical concept formulated by Mike Cohn and was introduced in his book, ‘Agile Estimating and Planning’. The test suite is organized into three layers — Unit, Integration, and E2E testing. Let’s learn more about them.

Unit Tests

Unit testing is a technique where individual modules are tested to determine whether they are suitable for use. The main aim of unit testing includes segregating each part of the system and ensuring that the individual components are working efficiently.

Integration Tests

Integration testing specializes in the interaction between two or more components used together in a test, and the result is validated. They are generally slower to run because it involves a complex setup.

Finding the problem could be a bit more complicated if integration tests fail because the failure range is greater. They’re also harder to code and maintain because they have more advanced mocking and increased testing scope. You can refer to this JUnit 5 Mockito tutorial to learn more about mocking.

End to End Tests

End to End testing is a technique used to test whether the flow of an application right from start to end is behaving as expected.

Benefits of End to End Testing

There are several benefits of End to End testing. When discussing the worth of End to End testing for a business, the benefits are often boiled down to some key points.

Testing from an end-user’s perspective

In unit tests, you verify each component in isolation, and end to end testing examines the application from the perspective of the end-users.

Health of the application

In End to End testing, the application is tested at all the layers — the business, data, integration, and presentation. This helps ensure the application being tested is free from bugs and works seamlessly across the lifecycle.

Since End to End testing validates the health of your application at every level, it keeps the health and well-being of your application at all times. Testing applications at the unit level rather than at the integration level provides a much-needed perspective on software overall performance throughout different levels and environments.

Increased test coverage

End to End tests can verify that each one of an application’s dependencies works correctly together, including third-party code.

End to End testing helps us to test the entire application, both at the API and UI layers, from start to finish. Using automated UI testing and manual testing practices aids in maximizing test coverage. You can learn more about it through this blog on how to move from manual testing to automation.

Decrease future risks

In End to End testing, the application is tested in-depth after every sprint and iteration. This helps testers locate defects faster and earlier in the life cycle. The chances of application failure in the testing (or production) process are prominently decreased.

Detection of bugs and issues sooner within the application development lifecycle minimizes testing efforts and costs. Extensive testing at every step ensures fewer bugs in the system and earlier identification of breakdowns in the software. This will reduce the repetition of tests and, therefore, ultimately, the associated effort, time, and costs.

Increases Confidence in product quality

End to End testing additionally increases the confidence in the functioning and performance of the application as the application is tested across multiple devices, browsers, and operating systems comprehensively.

End to End web application testing frameworks

Let’s look at some of the popular web frameworks for End to End testing.

Cypress

Cypress is a next-generation front-end testing framework built with modern JavaScript frameworks. Cypress comes with a bundle of test runners and a dashboard service that records and displays test results.

Cypress is most often compared to Selenium; however, Cypress is both fundamentally and architecturally different. Cypress is not coercible by the same restrictions as Selenium. Cypress allows us to write several types of tests: end-to-end, integration, and even unit tests. You can learn more about the differences with this Cypress vs Selenium comparison.

Cypress runs tests inside the browser, giving results almost identical to what the users would experience when using the application.

Cypress Trends on GitHub

The data below is gathered from the official site of Cypress GitHub repository:

Stars: 39.5k
Forks: 2.5k
Used By: 490k
Releases: 273
Contributors: 368

If you’re a developer or a tester, the Cypress 101 certification will prepare you to write tests faster and with greater confidence by giving you a clear understanding of the fundamentals of Cypress End to End testing.

WebdriverIO

WebdriverIO is a progressive automation framework built to automate modern web and mobile applications.

It simplifies the interaction with the app and provides a set of plugins that help you create a scalable, robust, and stable test suite.

WebdriverIO Trends on GitHub

The data below is gathered from the official site of WebdriverIO GitHub repository:

Stars: 7.6k
Forks: 2.1k
Used By: 43.1k
Releases: 209
Contributors: 424

Nightwatch.js

Nightwatch.js is an integrated, easy-to-use End to End testing solution for web applications and websites, written in Node.js. It uses the W3C WebDriver API to drive browsers and perform commands and assertions on DOM elements.

Nightwatch.js Trends on GitHub

The data below is gathered from the official site of Nightwatch.js GitHub repository:

Stars: 11.1k
Forks: 1.1k
Used By: 135k
Releases: 182
Contributors: 94

Protractor

Protractor is an End to End test framework for Angular and AngularJS applications. Protractor runs tests against your application running in a real browser, interacting with it as a user would.

Protractor Trends on GitHub

The data below is gathered from the official site of Protractor GitHub repository:

Stars: 8.8k
Forks: 2.4k
Used By: 1.8m
Contributors: 260

TestCafe

TestCafe framework is an open-source automation framework built with NodeJS. It supports JavaScript, TypeScript, and CoffeeScript out of the box, which means zero configuration is needed. TestCafe is distributed under an open-source MIT license and is managed by DevExpress.

TestCafe Trends on GitHub

The data below is gathered from the official site of TestCafe GitHub repository:

Stars: 9.4k
Forks: 655
Used By: 10.6k
Releases: 351
Contributors: 112

Benefits of Cypress End to End Testing

Before we look at the benefits of performing Cypress End to End testing, let’s look at a simple Cypress End to End testing scenario:

Suppose you have to login into the application, and search for some product on the site https://ecommerce-playground.lambdatest.io/ and then log out from the application. Here are the steps for the above scenario, which cover End to End flow from Log-in to → Product search → Logout.

Test Scenario

Open the URL https://ecommerce-playground.lambdatest.io/index.php?route=account/login.
Enter email “lambdatest@yourmail.com”.
Enter password “lambdatest”.
Click on Login.
Search for the product “VAIO”.
Verify the correct product is searched.
Click on My Account.
Click on the “Logout” link.
User logs out from the application.

Now let us look at the benefits of Cypress End to End testing. Cypress is a fast, easy, and reliable End to End testing framework. Cypress tests anything that runs on a web browser.

Traditionally, End to End tests are slower and more expensive. With Cypress version 9.2.0, there is a significant improvement in the End to End testing experience. Now we can automate the whole testing process from unit level testing to system testing. Using the dashboard feature of Cypress, we can track our test results easily.

Cypress is very easy to set up. Just install and start writing the test cases. You can integrate custom reporters with Cypress to view the results.

It has a dashboard feature for CI integration. You can record test results in Dashboard when running Cypress tests from your CI provider.

As per my experience, here are some of the awesome features of Cypress End to End testing:

Easy to set up

You can install Cypress using NPM or their desktop application too. Also, you don’t need to install any additional libraries, dependencies, drivers, servers, etc., as you have to do in the case of Selenium. Cypress is very easy to set up compared to other automation testing tools (or frameworks).

Write test case faster

Cypress is faster, and within a few min, you can start to write the test case. Cypress runs tests inside the browser, giving results almost identical to what the users will experience. It also has access to the network layer over the application, which allows us to control all the network requests.

Automatic waiting

In Cypress, we don’t need to add waits or sleeps to your tests. Cypress automatically waits for commands and assertions before moving on to the next step. Cypress not only waits for elements to be visible or AJAX to load but also for different requests to be sent or returned. You can go through this tutorial on the types of Waits in Selenium to learn more about waits.

Real-time reloads

In Cypress, you don’t need to reload the test case. As you make changes to your test case, it is intelligent enough to automatically trigger and run the test. This saves a lot of time in other tools we have to save and rerun the test case

Screenshots and videos

Screenshots are captured automatically on failure, or videos of your entire test suite
when run headlessly, and this is extremely useful when tests are failed. Since we can watch what happens when a series of test steps are running, it becomes very easy to track down the exact step when some test case fails.

Informative Dashboard

Using the Cypress dashboard, we can run our test cases in CI/CD providers and record test results. The Dashboard provides you insight into what happened when your tests ran. The dashboard lets you see the number of failed, passing, pending, skipped tests and the entire stack trace of failed tests. The screenshot captures itself when any test case fails, and by running the video, we can see the step of failure.

Integration with cloud testing platform

We can integrate Cypress with the various cloud-providing testing platforms. One of them is LambdaTest. Using Cypress automation tools like LambdaTest, you can execute & analyze Cypress test scripts online. You can run End to End tests on a blazing-fast Cypress test execution cloud. LambdaTest is a reliable, scalable, secure, and high-performing test execution platform built for scale. Perform Cypress UI testing on 40+ different browsers and browser versions, including headless versions.

Run End-to-End Cypress tests on cloud grid. Try LambdaTest Now!

Getting Started with Cypress End to End Testing

Follow the below-mentioned steps to create a new project for Cypress automation testing.

Step 1: Create a folder and generate package.json.

Create a project, here naming it as Cypress_Lambdatest.
Use the npm init command in the terminal to create a package.json file

Step 2: Install Cypress.

To install Cypress, run this command in the newly created folder:

npm install cypress — save-dev

This command will install Cypress locally as a dev dependency for your project.

yarn add cypress — dev

This command will install Cypress locally as a dev dependency for your project.

Once installed, Cypress version 9.2.0 is reflected, as seen below. The latest version of Cypress is 10.3.0

The default folder structure of Cypress is shown below. You can create test cases under the folder “integration”.

Project structure of Cypress

From the screenshots, you can see that Cypress has created a default folder hierarchy when it opens the first time. Below are the details for each of these folders/files created by Cypress.

**Fixtures: **Fixtures are external pieces of static data that your tests can use. It is recommended not to complex code data in the test case. It should be driven from an external source like CSV, HTML, or JSON.
Integration: This is the main folder to store all your tests. We add the Basic, End to End Test, Visual or Cucumber test here. All your spec files will be here.
Plugins: The Plugin folder contains the plugins or listeners. Cypress will automatically include the plugins file “cypress/plugins/index.js”.
Support: There are two files inside the support folder: commands.js and index.js
command.js: is the file where you add your commonly used functions and custom commands. It includes functions you may call to use in different tests, such as the login function. Cypress created some functions for you, and you can override them here if you want.
index.js: This file runs before every single spec file. This file is a great place to put global configuration and behavior that modifies Cypress like before or before. By default, it imports only commands.js, but you can import or require other files to keep things organized.
Node_Modules: All the node packages will be installed in the node_modules directory and available in all the test files. So, in a nutshell, this is the folder where NPM installs all the project dependencies.
Cypress.json: It is used to store different configurations. e.g., timeout, base URL, test files, or any other configurations we want to override for tweaking the behavior of Cypress. We can also manage the customized folder structure because it is part of, by default, Cypress Configurations.

Apart from the above four folders, we have some more folders like Screenshot, Download, and Video to store different related files, which we will discuss later.

Check this out: Run Automated Puppeteer Testing Online- Test your Puppeteer test scripts online.

Basic constructs of Cypress

Cypress has adopted Mocha’s syntax for developing test cases. Below are a few main constructs that are majorly used in Cypress test development:

describe(): It is used to group our tests. It takes two arguments, the first is the name of the test group, and the second is a callback function.
it(): It is used for individual test cases. It takes two arguments, a string explaining what the test should do and a callback function that contains our actual test.
before(): It runs once before all tests in the block.
after(): It runs once after all tests in the block.
beforeEach(): It runs before each test in the block.
afterEach(): It runs after each test in the block.
.only(): It is used to run a specified suite or test; append “.only” against the .it() block.
.skip(): It is used to skip a specified suite or test; append “.skip()” against the .it() block.

Demonstration: Cypress End to End Testing

Let’s create a new folder under the integration folder named “cypress_lambdatest” to perform Cypress End to End testing.

Cypress End to End Testing: Case Example 1

Create the first spec with the name login_searchproduct.spec.js under the folder LambdaTest.

Write the script below in the login_searchproduct.spec.js file, which covers login into the application and searching for the product. After the search, verify the correct product should be displayed.

In the code snippet below:

First, we open the site URL using cy.visit().
Second, it() block is used for log-in into the application by entering email and password.
Third, it() block is used for searching the product, and the last it() block is used for searching the product.

   /// <reference types="cypress" />
    it("Open the Url", () => {
     cy.visit(
       "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
     );
    });
    it("Login into the application", () => {
     cy.get('[id="input-email"]').type("lambdatest@yopmail.com");
     cy.get('[id="input-password"]').type("lambdatest");
     cy.get('[type="submit"]').eq(0).click();
    });
    it("Search the Product", () => {
     cy.get('[name="search"]').eq(0).type("VAIO");
     cy.get('[type="submit"]').eq(0).click();
    });
    it("Verify Product after search ", () => {
     cy.contains("Sony VAIO");
    });

Code Walkthrough

A new Cypress chain always starts with cy.[command], where what is yielded by the command establishes what other commands can be called next (chained).

Some methods, such as cy.get() or cy.contains(), yield a DOM element, allowing further commands to be chained onto them (assuming they expect a DOM subject) like .click() or even cy.contains() again

Cypress End to End Testing: Case Example 2

Create the second spec with the name *ScrollAnd_ClickProduct.spec.js *under the folder LambdaTest. Log in to → scroll to the bottom → and click on the product.

In the code snippet below:

First, we open the site URL using cy.visit().
Second, it() block is used for log-in into the application by entering email and password.
Third, it() block will click on the logo of LambdaTest.
Fourth, it() block will scroll to the particular product and click on it.

   /// <reference types="cypress" />
    it("Open the Url", () => {
     cy.visit(
       "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
     );
    });
    it("Login into the application", () => {
     cy.get('[id="input-email"]').type("lambdatest@yopmail.com");
     cy.get('[id="input-password"]').type("lambdatest");
     cy.get('[type="submit"]').eq(0).click();
    });
    it("Click on Lambdatest Logo", () => {
     cy.get('[title="Poco Electro"]').click();
    });
    it("Scroll to bottom and Click on Product 'iPod Touch' ", () => {
     cy.get('[title="iPod Touch"]').eq(0).scrollIntoView().click();
    });

Check this out: Mobile Emulator Online- Test your mobile websites and smartphone apps using our scalable on cloud mobile emulator.

How to perform Cypress End to End Testing on local Cypress Grid?

You can run the test case from the command line or use Cypress runner. Let’s run test cases using Cypress runner. To open the Cypress test runner, run the following command.

yarn run cypress open

The above command will open the Cypress test runner with the existing test cases. You can select the browser on which you want to run the test case.

Performing first Cypress End to End Testing on local Cypress Grid

Clicking on the first .spec, the first test case starts executing. Below is a screenshot of when the test case ran successfully.

Performing second Cypress End to End Testing on local Cypress Grid

Clicking on the second .spec, the second test case starts executing. In the below screenshot, we can see products are loading.

In the below screenshot the test case ran successfully.

Check this out: Regression testing: Complete Guide With Best Practices

How to perform Cypress End to End Testing on cloud Cypress Grid?

We have performed Cypress End to End testing on the local Cypress Grid. We can perform Cypress parallel testing on multiple browsers, versions, and operating systems using the cloud platform. Cloud-based cross browser testing platforms like LambdaTest allows you to automate web testing with Cypress on an online browser farm of real browsers and OS. We can perform Cypress End to End testing on a blazing fast test execution cloud.

LambdaTest offers high-scale parallelization with easy integration with CI/CD pipeline. Cypress test results will appear in real-time through the lambdatest-Cypress CLI. Once all test cases are executed, you can see the Cypress test results on the LambdaTest Dashboard. On LambdaTest, we can also see screenshots, videos, and logs for all test cases.

You can also Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around automated browser testing, Selenium testing, CI/CD, and more.

Check this out: 30 Top tools for Automation Testing In 2022

Step-up lambdatest for Cypress test case execution

Step 1: Install the CLI.

Install the LambdaTest using Cypress CLI command via npm. LambdaTest’s command-line interface allows us to run your Cypress tests on LambdaTest.

npm install -g lambdatest-cypress-cli

Step 2: Generate lambdatest-config.json.

Under the root folder, configure the browsers that we want to run the tests. Use the init command to generate a sample lambdatest-config.json file or create one from scratch. Use the below command.

lambdatest-cypress init

In the generated lambdatest-config.json file, pass the below information.

Fill required values in the section lambdatest_auth, browsers, and run_settings to run your tests.

{
 "lambdatest_auth": {
   "username": "username",
   "access_key": "access_key"
 },
 "browsers": [
   {
     "browser": "Chrome",
     "platform": "Windows 10",
     "versions": ["latest-1"]
   },
   {
     "browser": "Firefox",
     "platform": "Windows 10",
     "versions": ["latest-1"]
   }
 ],
 "run_settings": {
   "cypress_config_file": "cypress.json",
   "build_name": "build-name",
   "parallels": 2,
   "specs": "./cypress/integration/lambdatest/*.spec.js",
   "ignore_files": "",
   "feature_file_suppport": false,
   "network": false,
   "headless": false,
   "reporter_config_file": "",
   "npm_dependencies": {
     "cypress": "9.2.0"
   }
 },
 "tunnel_settings": {
   "tunnel": false,
   "tunnel_name": null
 }
}

Cut test execution time with Cypress Parallel testing. Try LambdaTest Now!

How to perform Cypress End to End Testing in Parallel on cloud Cypress Grid?
Run the below command to perform Cypress UI automation on LambdaTest.

lambdatest-cypress run

As we run the above command, test case execution starts on your local and parallelly on the LambdaTest platform.

Check this out: Online Automation Testing Platform- Accelerate your release velocity with blazing fast test automation cloud

Cypress End to End Testing Report on local environment

Below report is generated when we run the command lambdatest-cypress run in the local terminal.

In the below report, we can see test case login_searchproduct.spec.js and ScrollAnd_ClickProduct.spec.js successfully run on Firefox and Chrome.

Cypress End to End Testing Report on LambdaTest

In the below screen, you can see test cases start running on the Firefox browser.

You can see in the below console that log test cases are passed on the Firefox browser.

In the below screen, you can see test cases start running on the Chrome browser as well.

You can see in the below console that log test cases are passed on the Chrome browser.

For more detail, you can read through this blog on How To Perform Cypress Testing At Scale With LambdaTest.

Here’s quick video if you have doubts regarding how to handle iframes in Cypress.

Check this out: Ad Hoc Testing: A Comprehensive Guide With Examples and Best Practices

Summary

There are pros and cons to each testing method. Cypress End to End testing is the closest to real user testing, which is one of its main advantages. The closer the test is to mimic the user, the more likely it will catch issues the user might experience.

Overall, Cypress is a solid choice if you want to take your testing to the next level with some End to End tests