Forem: enriquee20

Cypress Testing Library: Getting Started Tutorial

enriquee20 — Tue, 20 Jun 2023 06:29:58 +0000

Writing maintainable tests for web user interfaces is critical for ensuring the reliability and stability of applications. As the software evolves and changes, it’s vital to have tests that can be easily maintained and updated to reflect the latest changes in the code.

As part of UI testing, it is necessary to focus on the application’s behavior rather than its implementation details. This is because implementation details can undergo frequent changes, and testing them can result in fragile tests that easily break when the implementation is modified.

On the other hand, focusing on the application’s behavior allows for more resilient tests that are less prone to breaking as the code changes. Remember that this approach also helps catch regressions and ensure the application continues functioning as intended, even if new features are added and others are modified.

To maintain the long-term viability of a test automation suite, it’s also vital to ensure it can handle components’ refactors without breaking. Refactors can involve changes to implementing components but not necessarily their functionality; also, those could be related to technical debt. Therefore, tests that rely on implementation details may fail when a refactor occurs, even though the component’s functionality remains unchanged.

In this blog on Cypress Testing Library, we will delve deeper into the concept of removing implementation details from our tests and instead focusing on behavior. By adopting this approach, your test scripts can remain robust and effective even when there are changes in the implementation of components.

Check out this blog on the mobile automation testing tools, we list the best 11 mobile automation testing tools with their advantages and business-friendly features.

Why Cypress for test automation?

The big question for you at this moment is why Cypress is still relevant compared to other tools like Playwright, WebdriverIO, or TestCafe in terms of UI test automation. At the time of writing this blog on Cypress Testing Library, Cypress had just announced the 12.12.0 release, which supports Angular 16 and updates the Debug page as part of the significant features. But for those still waiting on Safari as part of cross browser testing, sadly, you will be waiting a bit longer.

If you are looking at Safari or Multi-tabs Testing for your UI testing, you know Cypress is not your first option; perhaps you have already switched to Playwright or keeping your Selenium test suite. The question is still there, and it looks like Cypress is not relevant anymore, but Cypress is still relevant (Let’s rephrase it, tools like Cypress are more appropriate to these new Modern times), but why is this true, let’s dig in a bit more. You can learn more about it through this blog on Playwright vs Selenium vs Cypress.

Cypress and similar tools want to simplify writing tests; imagine Developers coding all day and following the Test Driven Development (TDD) methodology; it could be more challenging for them; now, what about the new QAs, in the past (Or present situation)? Installing Selenium and maintaining your WebDriver version or adding extra complexity to test a single component with more code doesn’t sound efficient.

Cypress wants to simplify that by providing easy solutions and making test automation an enjoyable experience for Developers, Testers, DevOps Engineers, and others.

This article will walk you through the best software testing certifications that will help boost your career as a test automation engineer.

Understanding the Problematic DOM-Testing

When writing tests for your web UI, prioritizing maintainability is essential. It means writing tests that avoid relying on the implementation details of your components. Instead, you should focus on testing the functionality of your application in a way that gives you confidence that it works as expected. By decoupling your tests from implementation details, you can ensure that your test scripts remain resilient to coding changes.

To achieve maintainable tests, you should focus on testing the external behavior of your components. It means testing what your users will see and interact with rather than how your components are implemented under the hood. You can achieve this by combining functional tests and integration tests, which help ensure our application works as intended from an end-to-end testing perspective.

If you want to prioritize maintainability, you must avoid the typical pitfall of tests that break after minor UI changes to our coding. In addition, it can help us and the team to save time and effort in the long run, as you won’t need to spend as much time fixing broken tests or updating them after every refactor. Finally, writing maintainable tests can help you build a more reliable and robust web UI that meets the needs of your users.

It sounds hard to write highly maintainable test scripts and avoid breaking changes; I know the solution could be more apparent, but believe me, the utilities this library provides facilitate querying the DOM as the user would. For example, it found form elements by their label text (just like a user would), links and buttons from their text (Similar like a user would), and more. In addition, it exposes a suggested way to find elements by a data-testid as an “escape hatch” for elements where the text content and label do not make sense or are impractical.

The DOM-Testing library encourages your applications to be more accessible. It allows you to get our tests closer to using your components the way a user will, which allows your tests to give you more confidence that your application will work when a real user uses it.

In this article on the top 9 challenges in automation testing, we look at the various obstacles and how to deal with them.

What is the Cypress Testing Library?

Cypress Testing Library is a JavaScript library that provides utilities and best practices for testing web applications using the Cypress testing framework. It is built on top of the popular testing library family of libraries, which promotes a user-centric approach to testing by emphasizing real-world user interactions and behavior. Cypress Testing Library extends the capabilities of Cypress and enables developers to write more maintainable and reliable Cypress UI tests for their web applications.

With Cypress Testing Library, you can write tests that closely resemble how users interact with your application. It encourages testing the application from the user’s perspective, focusing on the rendered output and the expected behavior. This approach helps to decouple the tests from implementation details, making them more resilient to changes in the application code.

The library provides a set of intuitive query methods to select and interact with elements on the page, just like a user would. It also offers various utility functions for common testing scenarios, such as checking for the presence of elements, interacting with form inputs, and making assertions on the rendered content. Cypress Testing Library promotes accessible and inclusive testing practices, ensuring that your application can be tested for a wide range of users.

Overall, Cypress Testing Library simplifies the process of writing effective and maintainable tests for web applications using Cypress, making it a valuable tool for developers seeking to enhance the quality and reliability of their Cypress e2e testing efforts.

Learn why Python is the top choice for automation testing. This comprehensive tutorial provides a step-by-step guide to Python automation testing to help you streamline your testing process.

Installing Cypress Testing Library

Now, it’s time to install the Cypress Testing Library in your Cypress project. Please type the following command:

npm install --save-dev @testing-library/cypress

If the installation is successful, you will see the Cypress Testing Library in our package.json file:

Cypress Testing Library extends Cypress’s cy commands. You must add the following line to our project’s cypress/support/commands.js:

    import '@testing-library/cypress/add-commands'

You can now use the DOM Testing Library’s findBy, findAllBy, queryBy, and queryAllBy commands off the global cy object.

Let’s start with a simple test, FindAllByTitle; we will use the following URL -> “https://ecommerce-playground.lambdatest.io/” as this is a good Automation playground from LambdaTest.

 it.only('findAllByText', () => {
            cy.findAllByText('Search')
                .should('have.length', 1)
        })

For this test, we are trying to find all the elements having the text “Search” in the current webpage as part of the DOM page; you should see only one.

As you can see in the image above, our webpage only has one element; that’s why it says “length of 1” But what about if the requirements mention two elements with Search’s Text? Let’s update our code and rerun it.

  it.only('findAllByText', () => {
            cy.findAllByText('Search')
                .should('have.length', 2)
        })

As you noticed, the Cypress assertion failed; we were expecting two elements with the Search text, but our web page’s current state displays only one; as the first part of our approach, it worked smoothly; we validated the behavior, let’s try another example.

 it.only('findAllByText', () => {
           cy.findAllByText('SHOP NOW')
           .should('have.length', 3)
       })

For the following example, we will find all the elements with the text “SHOP NOW”; I did a quick search, and it’s displaying 3, let’s go with that approach.

We got a failure; it looks like our test only found two elements; let’s see the Cypress highlight page; this is a good option if you are debugging your tests.

After debugging, we found the problem; we were looking for “SHOP NOW” in all Upper cases, but the other button contains the text “Shop Now” in Lower and Upper cases; let’s see if this is correct, rerun it with “Shop Now” text.

Now, let’s create our first UX bug per UX web design guidelines; you should have a standard design applicable to buttons, labels, titles, etc. Just kidding, but now you can witness the potential of DOM testing with Cypress.

It’s addictive; let’s use the Placeholder attribute, which is relevant for web Inputs; inputs are the gates nearly all eCommerce has to pass. Regardless of your feelings about empathy in design, unusable inputs leave money on the table. In this case, we will use findByPlaceholderText.

  it.only('findPlaceholders', () => {
           cy.get(`li:nth-of-type(6) > a[role='button']`).click()
           //
           cy.findByText('Continue').click()
           //
           cy.findByPlaceholderText('First Name').click().type('Hello Placeholder')
       })

As you can notice from the code above, we are using “findByText” and “cy.get“; the “get” we are using to find a specific element without any particular identifier; the rest is straightforward; let’s run it our test.

Last but not least, here you can find the list of queries you can perform using Cypress Testing Library

‘findByLabelText’,
‘findByPlaceholderText’,
‘findByText’,
‘findByDisplayValue’,
‘findByAltText’,
‘findByTitle’,
‘findByRole’,
‘findByTestId’

Code Walkthrough

Till now, you have understood the importance of the Cypress Testing Library. So, with the Cypress project already set, let’s look at how the code works using Cypress. For starters, please look at the link to set up Cypress; as mentioned before, Cypress enables you to write faster, easier, and more reliable tests.

Let’s start defining our config.json file; here, you can include some data and URLs.

   {
       "URL1": "https://www.lambdatest.com/blog/",
       "URL2": "https://ecommerce-playground.lambdatest.io"
    }

Next, you need to establish our structure. As demonstrated in the following line of code, import MainPage from ‘../../page-objects/components/MainPage’; we aim to separate our Cypress locators from our tests using the Page Object Model (POM) approach. This structure is located under the “page-objects” folder.

Let’s start defining a hook for our tests; with a couple of tests, things might get repetitive. For this case, you might instead use a beforeEach() hook that will open up your page before all of your tests; remember that Cypress clears out the state of the browser in between tests.

 describe('Testing Cypress Library', () => {
       beforeEach(() => {
           cy.visit(`${config.URL2}`)

Now, you probably noticed the following line of code -> “cy.visit(${config.URL2}) “; as I mentioned before, I like to put my URLs in a different file, “config.json” in this case you are wondering why not using the baseUrl inside of the cypress.config.js file, being honest, this is because switching URLs can be tricky, in my case, I use around four to five web pages to validate.

![](https://cdn-images-1.medium.com/max/2000/0*hwKOPbHwiCodcG-O.png)

    // Test each of the types of queries: LabelText, PlaceholderText, Text, DisplayValue, AltText, Title, Role, TestId

       it('findAllByText', () => {

           MainPage.FindByTextAll('Search', 1)
       })

       it('findAllByText', () => {

           MainPage.FindByTextAll('Shop Now', 1)
       })

       it('findAllByText Second', () => {

           MainPage.FindByTextAll('SHOP NOW', 2)
       })

       it('findPlaceholders', () => {

           MainPage.GoToCreateAccount()
           //
           MainPage.findPlaceholders()
       })

    })

Our methods and locators can be found in the “components/MainPage”. You can see that our tests look cleaner and easy to follow; currently, we have four tests; let’s explore the methods one by one.

 export default class MainPage {

       static GoToCreateAccount(){

           cy.get(`li:nth-of-type(6) > a[role='button']`).click()
           //
           cy.findByText('Continue').click()

       }

       static FindByTextAll(El1, qty){

           cy.findAllByText(El1)
               .should('have.length', qty)

       }

       static findPlaceholders(){

           //cy.findByPlaceholderText(El1).click().type(PlaceText)

           cy.findByPlaceholderText('First Name').click().type('Hello Placeholder')
           cy.findByPlaceholderText('Last Name').click().type('Hello Last Name')
           cy.findByPlaceholderText('E-Mail').click().type('Hello E-Mail')
           cy.findByPlaceholderText('Telephone').click().type('Hello Telephone')
           cy.findByPlaceholderText('Password').click().type('Hello Password')
           cy.findByPlaceholderText('Password Confirm').click().type('Hello Password Confirm')

       }

    }

As you can see from the code above, we have three methods, one for registering a new customer, in this case, “GoToCreateAccount“, another one for the “FindByTextAll” receiving two parameters, text, and the length, finally the “findPlaceholders” method, basically looking for all the Placeholders in the registering page, as this is a one-time method, no need to encapsulate more the repeatable FindByTextAll sentence.

Here is the result of our tests, which indicates that our Cypress Testing Library testing approach is working smoothly.

Run your Selenium Automation Testing scripts on the LambdaTest cloud grid. Test on 3000+ desktop & mobile environments. Try it for free!

When to use the Cypress Testing Library?

We try only to expose methods and utilities that encourage you to write tests that closely resemble how web pages are used.

Utilities are included in the Cypress Testing Library, and we encourage the following principles about when to use this library:

If it relates to rendering components, it should deal with DOM nodes rather than component instances and not encourage dealing with them.
It should generally test the application components and how the user would use them. We are making some trade-offs here because we’re using a computer and often a simulated browser environment, but in general, utilities should encourage tests that use the components how they’re intended to be used.
Utility implementations and APIs should be simple and flexible.

You must resemble how users interact with your code (component, page, etc.); for Cypress Testing Library, we recommend the following priority:

Semantic Queries HTML5. Remember that the user experience of interacting with these attributes varies greatly across browsers and assistive technology.

findByRole: It can be used to find every element exposed in the accessibility tree. With the name option, you can filter the returned elements by their accessible name. It should be your top preference for just about everything. There’s not much you can’t get with this (if you can’t, your UI may be inaccessible). Most often, this will be used with the name option like so: getByRole(‘button,’ {name: /submit/i}).
findByLabelText: This method is perfect for form fields. Users find elements using label text when navigating through a web page form. This method emulates that behavior, so it should be your top preference.
findByPlaceholderText: A placeholder is not a substitute for a label. But if that’s all you have, it’s better than alternatives.
findByText: Text content is the primary way users find elements outside forms. This method can find non-interactive elements (like divs, spans, and paragraphs).
findByDisplayValue: The current value of a form element can be helpful when navigating a page with filled-in values.
findByAltText: If your element supports alt text (img, area, input, and any custom element), you can use this to find that element.
findByTitle: The title attribute is not consistently read by screen readers and is not visible by default for sighted users

2. Test IDs

findByTestId: This approach is advisable only in situations where matching by role, or text is not feasible or meaningful (such as when the text is dynamic) since these attributes are not visible or audible to the user.

Cypress Testing Library supports both jQuery elements and DOM nodes. It is necessary because Cypress uses jQuery elements, while DOM Testing Library expects DOM nodes.

In addition to supporting both jQuery elements and DOM nodes, Cypress Testing Library’s true capabilities can be harnessed on Cypress cloud grid. Digital experience testing platforms like LambdaTest allow devs and QA to perform automation testing with Cypress on over 50+ real browsers and OS, including Chrome, Firefox, Edge, Electron, and WebKit.

Jenkins is an open-source automation server that is written entirely in Java. Learn how to do continuous integration with Jenkins with this comprehensive guide to Jenkins Tutorial.

It’s a Wrap

Writing maintainable tests for web user interfaces is essential to guarantee that applications are reliable and stable. Tests ensure the code works as expected and catch potential issues before production. However, as software evolves and changes over time, it’s essential to have tests that are easy to maintain and update. Maintaining tests that are tightly coupled to the implementation details of the code can take time and effort to manage, leading to test code that is complex and brittle.

This Cypress tutorial will help you create modular and flexible tests using Cypress Testing Library, making them current and focusing on business behavior. In addition, it helps to ensure that tests remain an effective tool for verifying the quality and correctness of the code.

“We must guarantee what we deliver works for everyone.” — Enrique A Decoss.

I hope the Cypress Testing Library works for your team; in the meantime, let’s continue exploring it and adapting it to our current testing needs. Feel free to leave any comments or suggestions.

Happy Bug Hunting!

How To Handle iFrames In Cypress

enriquee20 — Thu, 09 Feb 2023 08:27:39 +0000

In today’s web development world, finding standalone web apps is challenging. However, we can find most of these web apps work with each other where the integrations happen either from the Front-end or Back-end. One of the oldest yet simple integration strategies is using iFrames when examining these integrations.

The < iframe > element has a somewhat convoluted history; introduced by Microsoft around 1997 and supported in early versions of Internet Explorer, it was incorporated into HTML 4.0, banished from XHTML, and reintroduced in HTML5.

Using iFrames is a good idea from the modern web development perspective. Still, it decreases the app’s testability from the UI perspective. Each iFrame is treated as a separate document via the browser, adding extra steps in our automation testing code as we need to map our elements inside those iFrames; imagine the complexity of handling nested iFrames. In addition, it could create flake test scripts if we don’t operate them correctly.

Cypress is an excellent framework for testing the front-end and back-end, but interacting with iFrames could be tricky. Testing iFrames with automated testing tools is necessary for many web apps. In this tutorial on how to handle iFrames in Cypress, you will learn how to write reliable tests for web applications that use iFrames and run them on the cloud Cypress grid.

So, let’s get started!

What are iFrames?

An iFrame in plain English is considered a window onto another document or site; the element’s purpose is to place content from one HTML document in the context of another (Basically embedded things).

When we add an iFrame to a page, we look through a window from that page into another site, with full interactivity within that space. It is why Google Maps, YouTube, and others encourage users to embed their content using an iFrame element; rather than hosting any portion of the complex web app ourselves, our page views the web service through an integrated window.

iFrame usage was much more popular before the explosion of JavaScript on the web (Resuscitated with HTML5). However, it remains vital in today’s web world (Especially with React and Flutter webs). Therefore, if we use iFrames to display external content on our website, we must ensure they work correctly.

Why is it essential to test the iFrames on our web pages? The logical answer is to guarantee everything is working as desired. Therefore, we test iFrames during the functional testing phase. Also, we validate the E2E flows to determine if the entire application is working at the point where the end-user interacts with it.

For a website, it means testing the website as it appears in a real browser. You’ll be loading up the website, serving accurate content, and then writing scripts to ensure you see what you expect. So let’s stop giving more context and start doing something worthwhile. Working with iFrames and Cypress.io is possible, and let’s demonstrate Cypress test automation with some functional code.

Also, get started with this complete Selenium automation testing tutorial. Learn what Selenium is, its architecture, advantages and more for automated cross browser testing. Read more.

Is it possible to automate iFrames with Cypress?

Cypress has some difficulties working with iFrames primarily because for all built-in “cy” DOM traversal commands, there is an open Issue #136 about the iFrame support, saying that we can still use iFrames in Cypress. In this blog on how to handle iFrames in Cypress, we will share how to interact with DOM elements inside an iFrame.

For version purposes, we will use Cypress version 10.7; as a personal recommendation, always try stable versions before going directly to the latest version (Currently Cypress v12.5.1) as Cypress v11 has some changes related to Experimental features (cy.session errors), related Cypress v12, still evaluating the chrome web security configuration. Still using an older version of Cypress? or want to migrate to Cypress 10? Check out this blog on migrating your test automation suite to Cypress 10.

npm install cypress@10.7
Cypress v10.7 was released on 08/30/2022.

Features:

The experimental feature of Cypress Studio has been brought back. It offers a visual method to create tests within Cypress by recording actions against the Application Under Test (AUT). This feature is only accessible for end-to-end tests and must be turned on through the e2e.experimentalStudio flag.
Support for Svelte component testing has been introduced. This feature has been released as an Alpha version, indicating the possibility of changes that could cause breaking in future Cypress releases. The issue #23037 has been resolved with this feature.
The “Latest Runs” and “Average Duration” columns in the specifications list now have hover-activated actions to help connect the project to the Cypress Dashboard. This resolves issue #22932.
Instructions for connecting projects to the Cypress Dashboard and recording a first test run have been added as informational banners. Users who do not plan to use the Cypress Dashboard can dismiss the banners to avoid seeing them in the future, resolving issues #22933, #22934, #22798, and #22935.
The “Create Spec from Component” feature, introduced in v10.5.0, is now available for Vue.js projects with a custom specification pattern configuration. This resolves issue #23071.
Custom configuration for the Webpack dev server in Angular component testing projects can now be provided through the “projectConfig” key. This enables support for projects that do not follow Angular CLI conventions, addressing issue #23161.
The setSystemTime function has been introduced, allowing the Cypress clock to be set to a new time. This resolves issue #15424.

Performance:

The behavior of the cy.session() command has been improved such that it no longer clears the DOM after a validation function runs. As a result, the need for a cy.visit() command after running cy.session() when using a validation function has been eliminated, addressing issue #22368.

Now, let’s focus on the iFrame test part.

Step 1: First, we need to identify our iFrame inside the DOM and perform any action inside the iFrame.

Step 2: Write spec file cypress/e2e/e2e_tests/test-iframe-cypress.cy.js that visit our web page and identifies the iFrame; we will use “iframetester.”

cy.visit('https://iframetester.com/?url=https://www.lambdatest.com/blog')
    //let's test iframe
    cy.get('#iframe-window')

Our test looks good, and we can see the loaded iFrame.

Step 3: Let’s update our spec file to type something and click on search input for the LambdaTest blog web page. Those elements are located inside the document’s body iFrame element.

cy.visit('https://iframetester.com/?url=https://www.lambdatest.com/blog')
           //let's test iframe
           cy.get('#iframe-window')
               .should('be.visible')
               .should('not.be.empty')
               .then(($iframe) => {
                   const $body = $iframe.contents().find('body')

           cy.wrap($body)
               .find(`input[name='s']`)
               .type('Cypress{enter}')

           })

Unfortunately, the test fails; Browsers adhere to a strict same-origin policy. It means that browsers restrict access between < iframes > when their origin policies do not match.

Step 4: To enable cross-domain iFrame access, we must set the property chromeWebSecurity to false in the file cypress.config.js and re-run the test.

 module.exports = defineConfig({
      chromeWebSecurity: false,
      e2e: {
        setupNodeEvents(on, config) {
          // implement node event listeners here
        },
      },
    })

After that, our test looks ok!

However, what about nested iFrames accessing an iFrame into an iFrame?

Step 5: We will use the iFrames web page for testing purposes. In this case, we will click the “iFrame 2” button, “Click Me 2.”

We will use the “contentDocument” property; if the iFrame and the iFrame’s parent document are the Same Origins. It returns a Document that is the active document in the inline Frame’s nested browsing context.

cy.get("#frame1")
               .its('0.contentDocument')
               .its('body')
               .find('#frame3')
               .its('0.contentDocument')
               .its('body')
               .find('#frame4')
               .its('0.contentDocument')
               .its('body')
               .find("#click_me_4").click()

Let’s run our spec file and see if the button is clicked successfully.

Now, run your Playwright test scripts instantly on 50+ browser and OS combinations using the LambdaTest cloud. Read more.

How to perform iFrames testing with Cypress?

Now, let’s focus on Cypress and iFrame and understand the code step by step. We are using Cypress v10.7 for testing iFrames with Cypress.

Subscribe to the LambdaTest YouTube channel for tutorials around Selenium testing, Playwright browser testing, Appium, and more.

Code Walkthrough:

 import config from './config.json'
    import MainPage from '../../page-objects/components/MainPage'

    describe('iFrame Testing Cypress', () => {
       before(function(){
           cy.visit(`${config.URL3}`)
       })

       it('Verify iframe working', () =>{

           //let's test iframe
           MainPage.iframeInput("#iframe-window",`input[name='s']`)
       })

Let’s start defining our config.json file; here, we can include some data and URLs.

Next, we need to establish our structure. As demonstrated in the following line of code, import MainPage from ‘../../page-objects/components/MainPage’, we aim to separate our Cypress locators from our tests using the Page Object Model (POM) approach. This structure can be found within the “page-objects” folder.

As mentioned above, our methods and locators can be found there; in our example, we try to search on Google using an iFrame webpage (embedded Google search).

 describe('iFrame Testing Cypress', () => {
       before(function(){
           cy.visit(`${config.URL3}`)
       })

For this case, we are using a before() hook that will open up our page before all of our tests, and after that, we can test, keeping in mind if we need to switch URLs, we must use “cy.origin” as we will mention below.

it('Verify iframe working', () =>{

           //let's test iframe
           MainPage.iframeInput("#iframe-window",`input[name='s']`)
       })


    export default class MainPage {

       static iframeInput(iframe_el,ele1){
           cy.get(iframe_el)
               .should('be.visible')
               .should('not.be.empty')
               .then(($iframe) => {
                   const $body = $iframe.contents().find('body')
           //
           cy.wrap($body)
               .find(ele1)
               .type('Cypress{enter}')
           })
       }
    }

Here’s this tutorial, learn what is Regression testing, its importance, types, and how to perform it.

Slow loading and empty iFrames validation

Let’s understand the code below; first it is vital to get the iFrame locator. Since, as we know, many iFrames are a bit slower to load, or sometimes iFrames are broken, for those cases, we must implement some assertions “be.visible” or “not.be.empty” can do the work. Second, assign an alias, and then we can navigate inside the elements of the iFrame.

Reusing our Code

We will probably access the iFrame’s elements in multiple tests; as we can see, we are using a static method and a class. The other approach is using Cypress custom commands inside the cypress/support/index.js. Not a big fan of using custom commands, but you can reuse the same code and create a custom command.

We can now see that after it went through all those steps, it was able to grab the body of the iFrame. So then we can wrap it with Cypress, using that .find() to navigate inside the iFrame body.

Cypress wrap command is used to yield objects placed in it and their resolved value, meaning that when you want to use Cypress commands like should, type, or click on an object or jQuery element, you should wrap.

Here's a complete Selenium WebDriver tutorial that covers what WebDriver is, its features, architecture and best practices.

Nested iFrames

What about dealing with nested iFrames? It could be a nightmare and happens very often on multiple web pages. In those cases, we can use the “contentDocument” approach, which is relevant when navigating with various iFrames, as we can see from the image.

it("Using 'contentDocument' - Nested iframes", () => {

           cy.origin(`${config.URL4}`, () => {
               cy.visit('/frames.html')
               cy.get("#frame1")
                   .its('0.contentDocument')
                   .its('body')
                   .find('#frame3')
                   .its('0.contentDocument')
                   .its('body')
                   .find('#frame4')
                   .its('0.contentDocument')
                   .its('body')
                   .find("#click_me_4").click()
               //
           })   
       })

Cross-origin E2E

One last part I would like to discuss is the “cy.origin”, as we are using version 10.7. This feature is not fully available if we don’t activate the experimental feature -> “experimentalSessionAndOrigin: true.” As you probably noticed, we used a new domain -> “https://www.play1.automationcamp.ir” but also we need to visit the specific web page.

`cy.origin(`${config.URL4}`, () => {
           cy.visit('/frames.html')`

Here is the test execution, which indicates that our Cypress iFrame testing approach is working:

In the next section of this tutorial on how to handle iFrames in Cypress, we will learn how to run our tests in the Cypress cloud grid.

LT Browser is a live mobile friendly test tool. It helps you to perform live mobile friendly test on multiple screen resolutions while surfing your website.

How to handle iFrames in Cypress on the cloud grid?

We can utilize a Cypress cloud grid such as LambdaTest, which offers automated cross-browser testing on over 40 browsers and operating systems, and Cypress parallel testing to speed up test execution and facilitate large-scale Cypress testing. This will result in enhanced overall test coverage, leading to a better quality product, as we can test various combinations using the same test scripts.

To get started with Cypress e2e testing, follow the below-mentioned steps:

Install LambdaTest Cypress CLI on your machine. Trigger the following command to install the same:

npm install -g lambdatest-cypress-cli

After installation is completed, set up the configuration using the below command:

lambdatest-cypress init

Once the command is completed, lambdatest-config.json is created in the project folder. Next, enter the LambdaTest credentials from the LambdaTest Profile Section.

 "lambdatest_auth": {
          "username": "<Your LambdaTest username>",
          "access_key": "<Your LambdaTest access key>"

Here is how you can configure the required browser & OS combinations in lambdatest-config.json:

 {
      "lambdatest_auth": {
         "username": "",
         "access_key": ""
      },
      "browsers": [
         {
            "browser": "MicrosoftEdge",
            "platform": "Windows 10",
            "versions": [
               "latest"
            ]
         },
         {
            "browser": "Chrome",
            "platform": "Windows 11",
            "versions": [
               "latest"
            ]
         },
         {
            "browser": "Chrome",
            "platform": "MacOS Monterey",
            "versions": [
               "latest"
            ]
         }
      ],

The run_settings section in the JSON file contains the desired Cypress test suite capabilities, including Cypress_version, build_name (Cypress-iframe), number of parallel sessions, etc.

"run_settings": {
         "cypress_config_file": "cypress.config.js",
         "build_name": "build-Cypress-iframes",
         "parallels": 5,
         "specs": "./cypress/e2e/e2e_tests/*.cy.js",
         "pluginsFile": true,
         "ignore_files": "",
         "npm_dependencies": {
            "cypress": "10.7.0"
         },
         "feature_file_suppport": true
      },

The “tunnel_settings” in the JSON file allows you to establish a connection between your local system and the LambdaTest servers through an SSH-based integration tunnel. With this tunnel in place, you can test locally hosted pages on all browsers supported by Cypress on LambdaTest.

  "tunnel_settings": {
        "tunnel": false,
        "tunnelName": null
    }

With the setup complete, it’s time to run the tests. Keep in mind that the “parallels” field in the “run_settings” file is set to five, meaning the tests will run in parallel without additional parameters. Note that the code used in previous tests remains unchanged when utilizing the cloud grid.

lambdatest-cypress run
Shown below is the test execution status from the LambdaTest Automation Dashboard.

If we click on any of the tests, we can see the details of our Cypress test scripts video of the execution and the actual code executed in Cypress Grid; pretty neat.

Now, let’s see more details about our test code, click on the button next to our test title. It will open a page, and we can explore our code or identify some issues in case of failure.

To view test performance metrics, go to the LambdaTest Analytics Dashboard. The Test Overview provides an overview of tests with stable behavior, while the Test Summary shows the total number of passed or failed tests and any completed or pending tests.

If you are a developer or a tester and have a basic understanding of Cypress and want to take your knowledge to the next level, then this Cypress 101 certification course is for you.

In this tutorial, learn what is Regression testing, its importance, types, and how to perform it.

Wrapping Up

Working with iFrames could be a big deal with Cypress, but I hope this blog on how to handle iFrames in Cypress helps you overcome common issues I ran into with them. Even though Cypress has limitations with iFrames, there are ways to work around them.

“We must guarantee what we deliver works for everyone.” — Enrique A Decoss.

I hope the Cypress team addresses the native way to use “switchToFrame” soon; in the meantime, let’s continue using the workarounds available. Feel free to leave any comments or suggestions.

Happy Bug Hunting!

How To Write End-To-End Tests Using Cypress App Actions

enriquee20 — Wed, 08 Feb 2023 10:43:46 +0000

When I started writing tests with Cypress, I was always going to use the user interface to interact and change the application’s state when running tests.

This could be beneficial since it gives you the same behavior as an end-user interacting with the application.

But this is only sometimes the case. Sometimes, you only need to manipulate the state in your application without using the UI.

You might have already tested it in a different test case and only need the state to test the next feature. In this case, using the UI to interact with the application could be redundant and time-consuming.

However, there is another way to bypass the UI and manipulate the state of your application to get the results you want without using the user interface, giving you a fast and instant result.

If some of your tests require the actual state to be available inside your application, you no longer need to use the UI. Instead, you can use App Actions.

In this blog on Cypress App Actions, you will learn how Cypress App Actions differs from Page Object Model and how you will run tests with Cypress App Actions in a cloud grid like LambdaTest.

What are App Actions?

App Actions are shortcuts or actions inside your application that will help you change and manipulate your application’s state without using the graphical user interface (GUI).

Actions are one of the most exciting new features of Cypress automation tool. They enable you to extend your app’s functionality by adding an unlimited number of custom commands. They are the equivalent of writing a Cypress module but with much higher developer velocity.

Each action has its state, so any time the state changes, the test will be re-run automatically. With Cypress App actions, you can automatically log users, fill out forms, click buttons, and much more with little or no effort.

Now, perform manual or automated cross browser testing web on 3000+ browsers online. Deploy and scale faster with the most powerful cross browser testing tool online.

Cypress App Actions vs. Page Object Model

The page object model is a popular design pattern when it comes to Cypress E2E testing.

The Cypress page object model serves some good purposes, like preventing code duplication, but like anything else, the page object model design pattern has its pros and cons.

Page Object Model (POM)

Page objects help to keep tests organized and maintainable by encapsulating DOM interactions into reusable functions. This way, if the UI changes, you only need to update the page object methods rather than doing changes in your entire test suite.

However, page objects can easily become too long to read or understand when your project grows larger and larger, making it challenging to find the relevant code for a particular test.

App actions, on the other hand, are written as general-purpose functions that can be reused across multiple tests. The most important benefit to Cypress App Actions is that it completely bypasses the user interface, making your test suites much more performant.

This makes them more flexible since you can create many custom actions, but also more difficult to debug since there is no clear structure. When deciding which approach to take, it’s essential to weigh the tradeoffs and decide what will work best for your specific needs.

Shortcomings of Page Object Model?

Page objects can be tricky to work with because they introduce an additional state level into your tests that is separate from the application’s initial state.
Page objects make it difficult for you to debug and may lead you astray when trying to understand exactly what went wrong with a test case since the tests depend on the previous state instead of the initial state of the application.
Page objects could make your test cases extremely slow and inefficient since they always have to use the user interface to interact with the application.

It’s crucial to debug websites for Safari before pushing them live. In this article, we look at how to debug websites using Dev tool in Safari.

Why Cypress App Actions?

Let’s say we have a sample to-do application in which a user can add and delete to-do items, and there are also featureful to-dos at once.

Let’s say we want to test the button which deletes all to-dos. To perform Cypress testing of this feature, we first visit the page with Cypress, add the to-dos, and then press the delete button to see if this new feature works.

If we have done this the regular way (using the graphical user interface) and not by using Cypress App Actions, it will take some time for Cypress to type some to-dos in a text input and add them one by one. Therefore the application needs more time to be thoroughly tested.

However, this amount of time looks insignificant in this basic example. What if you had an extensive application and your tests needed the application to run some actions for them to run?

If you decide to use the GUI, it will significantly lower your application’s performance and make your test suites run for hours.

That’s when Cypress App Actions come in, with app actions, you no longer need to interact with the user interface.

If you want some to-dos to be added to the list, you can easily write an action inside of your application (app action), which will do that for you without interacting with the graphical user interface, making it work instantly, cutting out all the time required for the user interface to respond.

How to run tests using Cypress App Actions?

I will create a simple one-page front-end-only to-do list application where users can add, check, uncheck, and delete to-dos.

The application is written in React with the help of TailwindCSS to make it look better. Here is the code of the application.

// App.jsx
    import React, { useState } from 'react'

    const App = () => {
      const [todos, setTodos] = useState([])
      const [input, setInput] = useState('')

      const addTodoHandler = e => {
        e.preventDefault()
        if (!input) return
        setTodos([...todos, { title: input, done: false }])
        setInput('')
      }

      const updateTodoHandler = (index, done) => {
        const newTodos = [...todos]
        newTodos[index].done = done
        setTodos(newTodos)
      }

      const deleteHandler = index => {
        const newTodos = todos.filter((todo, i) => i !== index)
        setTodos(newTodos)
      }

      const deleteAll = () => {
        setTodos([])
      }

      return (
        <div className='w-full p-10 max-w-md mx-auto flex flex-col gap-5'>
          <h2 className='text-center font-bold text-3xl mb-4'>To do APP</h2>

          <form className='flex flex-col gap-1' onSubmit={addTodoHandler}>
            <input
              className='outline-none px-5 py-2 rounded-lg border'
              placeholder='Add new todo'
              type='text'
              data-cy='new-todo-input'
              value={input}
              onChange={e => setInput(e.target.value)}
            />
            <button
              data-cy='submit-button'
              className='py-2 px-5 rounded-lg bg-gray-100 hover:bg-gray-200 active:bg-gray-100'
            >
              Submit
            </button>
            <button
              onClick={deleteAll}
              type='button'
              data-cy='delete-all-button'
              className='py-2 px-5 rounded-lg bg-red-100 hover:bg-red-200 text-red-500'
            >
              Delete All
            </button>
          </form>
          <div className='flex flex-col gap-5'>
            {todos?.map((todo, _idx) => (
              <div
                key={_idx}
                data-cy='todo-item'
                className='flex justify-between items-center select-none gap-5 p-2 border rounded-lg cursor-pointer hover:bg-gray-100'
              >
                <div className='flex items-center gap-2 w-full'>
                  <input
                    onChange={e => updateTodoHandler(_idx, e.target.checked)}
                    checked={todo.done}
                    type='checkbox'
                    data-cy='todo-checkbox'
                  />
                  <p data-cy='todo-title'>{todo.title}</p>
                </div>

                <button
                  onClick={() => deleteHandler(_idx)}
                  className='text-sm text-red-500  hover:bg-red-100 rounded-sm p-2 z-50'
                  data-cy='todo-delete-button'
                >
                  Delete
                </button>
              </div>
            ))}
          </div>
        </div>
      )
    }

    export default App

As you might have noticed, I have added a new attribute for specific HTML tags, for example, the submit button has a new attribute of data-cy='submit-button’ this will be useful as a selector in our spec files to get access to the element, this is also one of the best practices of writing tests for Cypress test automation.

We can also create a new custom command in our cypress/support/commands.js file for this selector and re-use it later on.

Cypress.Commands.add('getBySel', (selector, ...args) => {
      return cy.get(`[data-cy=${selector}]`, ...args)
    })

Example usage:

    cy.getBySel('submit-button').should(...)

This is what the application looks like:

Now that it is set up and works perfectly, it is time to install Cypress and write some tests.

Installing Cypress

Installing Cypress is quite easy and straightforward.

1- Run the following command to install Cypress.

yarn add -D cypress

2- Add the following scripts to your package.json file.

{
        "cypress:open": "cypress open",
        "cypress:run": "cypress run"
    }

3- Now that Cypress has been installed, run the following command to launch Cypress.

 yarn cypress:open

4- Select E2E testing after Cypress launches.

5- Click Continue.

6- Choose your preferred browser (I will use Chrome).

7- After your browser opens up, click on “Create new empty spec”.

8- This will create a new spec file in which we can write our tests.

9- Now, our spec has been added to the cypress/e2e folder, and we can run it with Cypress.

This article explains the emulator vs simulator vs real device differences, the learning of which can help you select the right mobile testing solution for your business.

Editing the Cypress configurations

Since we are running a React application, I will set the baseURL of the Cypress configurations so that we can access our app easily.

Here is my Cypress config file in ./cypress.config.js

  // cypress.config.js
    const { defineConfig } = require('cypress')

    module.exports = defineConfig({
      e2e: {
        setupNodeEvents (on, config) {
          // implement node event listeners here
        },
        // setting up the base URL of our application
        baseUrl: '<http://localhost:3000>'
      }
    })

As I mentioned above, our goal here is to do some tests that require the application to at least have two or three to-do entries inside of it.

If we had to use the old approach to run these tests, we’d have to use the user interface to type the todo titles and add them to the list, and after that, run the tests on them.

So let’s try it and see why it’s not the right choice.

Running tests without Cypress App Actions (regular approach)

This is how the tests are written without Cypress App Actions (using the UI).

describe('Todo application', () => {
      beforeEach(() => {
        cy.visit('/')

        todos.forEach(todo => {
          cy.getBySel('new-todo-input').type(todo)
          cy.getBySel('submit-button').click()
        })
      })

      it('should delete all todos', () => {
        cy.getBySel('delete-all-button').click()
        cy.getBySel('todo-item').should('not.exist')
      })

      it('should delete one entry', () => {
        cy.getBySel('todo-delete-button')
          .first()
          .click()
        cy.getBySel('todo-item').should('have.length', todos.length - 1)
      })

      it('should delete multiple entries', () => {
        // deletes two items
        for (let i = 0; i < 2; i++) {
          cy.getBySel('todo-delete-button')
            .first()
            .click()
        }

        cy.getBySel('todo-item').should('have.length', todos.length - 2)
      })

      it('should check one item', () => {
        cy.getBySel('todo-checkbox')
          .first()
          .click()

        cy.getBySel('todo-checkbox').should('be.checked')
      })

      it('should check multiple items', () => {
        cy.getBySel('todo-checkbox')
          .first()
          .click()

        cy.getBySel('todo-checkbox')
          .eq(1)
          .click()

        cy.getBySel('todo-checkbox')
          .first()
          .should('be.checked')
        cy.getBySel('todo-checkbox')
          .eq(1)
          .should('be.checked')
      })
    })

As you can see in the beforeEach hook, we are inserting some data into the application, this happens before each of the tests or it blocks.

Now, let’s run the tests and see why this method of testing applications is actually not optimal or efficient.

The total time required for the tests to complete was 9 seconds, for such a small application like this, it is considered a very low performant test suite.

Also, this depends heavily on the user interface and element selectors, if one of the selectors of your application changes in future updates, your code will not be able to locate the elements and your tests will easily fail.

Need a great solution for cross browser testing on Safari? Forget about emulators or simulators — use real online browsers. Try LambdaTest to test on safari browser online.

Using Cypress App Actions

Now it’s time to run the same Cypress UI tests using app actions and see why they are a better choice and how they can improve the test performance.

In order to use certain functions inside of our application, we have to set it as a property of the window object and re-use those functions inside our spec files.

So, let’s add the functions that we want to the window object

 useEffect(() => {
        if (window.Cypress) {
          // the "todos" argument will be an array of todos
          // example: [{ title: "Run some tests", done: false }]
          window.addTodos = todos => setTodos(todos)
        }
    }, [])

With the use of the useEffect lifecycle hook, we’ll be able to use the window object inside of a React application, read more about React useEffect hook.

The addTodos function will enable us to send an array of to-dos to the application without using the user interface.

Now we can use the addTodos function inside of our spec files.

To access the window object, Cypress has provided us with the window() function, which we can call anywhere in our tests. We chain the invoke() function to it and pass the method’s name on the window object and the arguments it requires.

The spec file for app actions ./cypress/e2e/spec.cy.js

 let todos = ['Buy milk', 'Buy eggs', 'Buy bread', 'Buy butter', 'Buy cheese']

    describe('Todo application', () => {
      beforeEach(() => {
        cy.visit('/')

        cy.window().invoke(
          // name of the method
          'addTodos',
          // ...args (in this case we only have one argument "todos")
          todos.map(todo => ({ title: todo, done: false }))
        )
      })

      it('should delete all todos', () => {
        cy.getBySel('delete-all-button').click()
        cy.getBySel('todo-item').should('not.exist')
      })

      it('should delete one entry', () => {
        cy.getBySel('todo-delete-button')
          .first()
          .click()
        cy.getBySel('todo-item').should('have.length', todos.length - 1)
      })

      it('should delete multiple entries', () => {
        cy.getBySel('todo-delete-button')
          .first()
          .click()

        cy.getBySel('todo-delete-button')
          .first()
          .click()

        cy.getBySel('todo-item').should('have.length', todos.length - 2)
      })

      it('should check one item', () => {
        cy.getBySel('todo-checkbox')
          .first()
          .click()

        cy.getBySel('todo-checkbox').should('be.checked')
      })

      it('should check multiple items', () => {
        cy.getBySel('todo-checkbox')
          .first()
          .click()

        cy.getBySel('todo-checkbox')
          .eq(1)
          .click()

        cy.getBySel('todo-checkbox')
          .first()
          .should('be.checked')
        cy.getBySel('todo-checkbox')
          .eq(1)
          .should('be.checked')
      })
    })

Now, let’s run the tests and see the performance of the test suite.

As you can see, we are running exactly the same tests that we did before, but now we are getting a total time of tests of only 1 second which is almost 800% more efficient than the previous test.

This will make your application much more performant in the long run, which would have been very difficult to run if we’d had to interact with the UI.

Check this article, and look at some aspects of ios emulator for pc and discuss some ways through which we can use iPhone Simulator on Windows.

Bonus: Running Cypress App Actions in the cloud with LambdaTest

LambdaTest’s latest feature (HyperExecute) now allows developers to run their end to end tests with the latest Cypress version available (Version 10.0).

In this short tutorial on Cypress App Actions, I will show you how to run the same tests we wrote in the Cypress cloud on LambdaTest.

LambdaTest provides an online device farm that allows you to run your Cypress automation tests on over 50 different real browsers and operating systems to increase the overall test coverage of your web application. This is achieved by running the same test scripts on various combinations of browsers and operating systems.

Check out the Cypress tutorial below to dive deep into the basics of the Cypress framework.

Subscribe to the LambdaTest YouTube channel for tutorials around Selenium testing, Playwright browser testing, Appium, and more.

Changing the configurations

Before starting configuring our tests for LambdaTest, let’s make our application available on a public URL.

I have deployed the to-do application on Vercel, which is public and available for LambdaTest to run tests on.

Updating the cypress.config.js

const { defineConfig } = require('cypress')

    module.exports = defineConfig({
      e2e: {
        setupNodeEvents (on, config) {
          // implement node event listeners here
        },
        // changed
        baseUrl: 'https://app-actions-cypress.vercel.app'
      }
    })

Now our application is ready to be tested on LambdaTest.

Downloading the HyperExecute CLI

Go to this page and scroll until you see the table for the HyperExecute CLI executable files and download the one for your operating system.

After you do that, move the file to the root directory of your application ./hyperexecute.exe

HyperExecute YAML file

All the test configurations that we need relating to LambdaTest will be specified inside this file.

Now, create a .ymlwith a name of your choice; I have named it LambdaTest.yml. This is what my YAML file looks like for this specific test.

 version: 0.1
    runson: win
    cypress: true
    concurrency: 2
    autosplit: true

    pre:
      - npm install
      - npm install cypress --save-dev
    cacheKey: '{{ checksum "package.json" }}'
    cacheDirectories:
      - node_modules
    testDiscovery:
      mode: static
      type: raw
      command: ls cypress/e2e
    testRunnerCommand: npx cypress run  --spec ./cypress/e2e/$test --browser=chrome-95.0 --headed --config video=false
    cypressOps:
      Build: "Hyperexecute Cypress Sample Build"
      Tags: ["Hyperexecute", "Cypress", "Windows", "Autosplit"]
      BuildTags: ["Hyperexecute-Cypress"]

The testDiscovery key is very important, with this, you can tell LambaTest where to look for your test files, and you can specify your directory inside of the command property.

In my case, I have only one spec file, which is inside the ./cypress/e2e/ directory. The ls cypress/e2e command ensures that every file inside that directory will be picked up and tested.

With the testRunnerCommand key, you can run a regular Cypress command. You can also configure it by specifying arguments and flags. In this case, we are specifying it to run on a chrome browser version 95.0, and the browser is headed, etc.

After this, we can perform Cypress UI automation on LambdaTest by uploading the tests using the HyperExecute CLI.

In your terminal, run the following command:

    ./hyperexecute.exe --user <your-lambda-test-username> --key <your-lambda-test-access-key> --config <your-.yml-file>

After replacing the user, access key, and config flags with your actual LambdaTest username and access key, and the YAML configuration file, in this case, LambdaTest.yml, run the command.

You can get your access key through the HyperExecute tab in the LambdaTest dashboard.

HyperExecute will pick up the configurations and upload your test files to LambdaTest.

You will also see your tests running on the HyperExecute tab on LambdaTest.

You can see the status of your tests either by looking up the test on the LambdaTest dashboard or the HyperExecute CLI.

The Cypress 101 certification is intended for those who have already acquired some familiarity with Cypress and wish to improve their understanding and end-to-end testing skills. It is suitable for developers and testers who want to take their Cypress knowledge to the next level.

Here’s 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.

Conclusion

App Actions and Page Object Model are two different ways to test an application, but they have their use cases.
App actions, as the name suggests, are about writing down actions in the application code, which can change the state of your application and re-using them inside your test suites.

A Step-By-Step Guide To Cypress API Testing

enriquee20 — Tue, 07 Feb 2023 08:57:26 +0000

A Step-By-Step Guide To Cypress API Testing

API (Application Programming Interface) is a set of definitions and protocols for building and integrating applications. It’s occasionally referred to as a contract between an information provider and an information user establishing the content required from the consumer and the content needed by the producer.

Cypress is a popular and user-friendly testing framework for end-to-end (E2E) testing of web applications. It is particularly popular among developers and testers familiar with JavaScript, as it does not require additional libraries, dependencies, or drivers to install. Cypress can be easily installed using the Node Package Manager (NPM) and does not require additional setup or configuration. This makes it a good choice for those looking to quickly and easily set up E2E testing for their applications.

Why Cypress for API testing? Can we have a test automation tool for everything? It could sound like a utopian dream for every company and testing team, but we can cover almost all possibilities with Cypress automation tool. It is a next-generation front-end testing framework; it constructs HTTP requests on behalf of the web applications as it is running. Although it might seem that Cypress is making these requests from the browser, it utilizes Node.js as the motor to create the HTTP requests to the API server.

Test your Puppeteer testing scripts online. Deploy a quality build faster by running automated checks across over 3000+ browsers and OS combinations with the LambdaTest cloud.

In this blog on Cypress API Testing, you will learn how to use Cypress to write cleaner and more efficient code for API test automation.

So, let’s get started!

Introduction to API Testing

API testing is a form of software testing accomplished as a part of integration testing to determine if they satisfy functionality, reliability, performance, and security expectations. API testing has recently been considered critical to the software testing process as it is faster and more reliable than UI-based tests.

In addition, API testing allows the testers to find bugs earlier in the development process, usually before the UI is created. Finally, API testing allows requests that might not be allowed through the UI (Sometimes, the UI is not ready during API development).

Understanding the flow of our APIs is necessary before starting to test them, and we need to understand a few essential technical requirements of the APIs.

API Endpoints

An API endpoint is the entry point in a communication channel where two software mediators interact. The endpoint can be seen as how the APIs can access the resources they require from a server to fulfill their tasks. An API endpoint is a fancy word for a server or service URL. For example, https://api.linkedin.com/v2/simpleJobPostings is the endpoint for LinkedIn’s job posting API, or we can use https://api.lambdatest.com/automation/api/v1 endpoint for getting data from the LambdaTest platform.

Methods Supported

We need to understand the methods (POST, GET, PUT, DELETE, PATCH) supported by the API. Keep in mind those as we need to test them.

Input-Output Schema

It is essential to comprehend the type of input required and the response body content for the API (JSON, plain text, XML, or other).

Response Codes

The response or status code is the most crucial API output that must be verified. The API response status codes are included in five classes or types. The first digit of the response code represents the response class, while the last two digits do not have any classification or categorization roles. The standard defines five types:

1xx Informational response — the request was received, resuming the process.
2xx Successful — the request was received, comprehended, and accepted.
3xx Redirection — further action must be taken to complete the request.
4xx Client error — the request contains the wrong syntax or cannot be fulfilled.
5xx Server error — the server failed to fulfill a valid request.

You can read through our earlier blog that deep dives into the HTTP Status request to learn more about it.

Headers and Auth Requirements

API calls demand a variety of header fields. Headers include a wealth of information that can help track down issues when they occur.

Typically, headers contain information regarding the request, response body, and request authorization. In addition, authentication is essential to confirm the credentials of a connection attempt. Therefore, most commercial APIs require API Key-based Authentication for their services (LambdaTest API Documentation).

Are you interested in learning more about API testing? Check out the TestuConf 2022 Phase Angle of API.

In this XCUITest tutorial, learn about XCUITest framework and its benefits for mobile automation testing. Take a look at how XCUITest works and see how to use it to test your mobile applications.

Rest and GraphQL API Testing using Cypress

In REST, an API endpoint is requested using the HTTP protocol to serve the data that the client needs, and the server returns the response based on the requested query. REST is a set of architectural practices, not a protocol or a standard. Therefore, API developers can implement REST in a variety of ways.

GraphQL, as a query language, defines specifications of how a client application can ask for the required data from a remote server. As a result, the server application produces a response to the requested client query. The exciting thing to notice in GraphQL is that the client application can also query what it requires without relying on the server-side application to determine a query.

Now we can start using Cypress for API testing, as Cypress is a standalone frontend automation testing tool; it creates HTTP requests on behalf of the web applications as it is executing. Cypress might appear to make these requests from the browser; it uses Node.js as an engine to make the HTTP requests to the API server.

For Cypress UI automation, I’m currently using version 9.7.0; at this point, we don’t require any cool new experimental features for our Cypress API testing project. Regarding API testing Rest and GraphQL, we will use the Go REST website; let’s start with some basic test scripts to get familiar with automated Cypress API testing.

Let’s code our first test and get all the users from our API user’s endpoint; we will use an HTTP request with the syntax cy.request (options):

For the code above, we make a ‘GET‘ request to our users in the ‘gorest’ API route. We assert that the response returns a 200 status code and prints the body response for that request. Now let’s run it and see the Cypress Test Runner result:

Let’s understand the code above; we are using cy.request with some parameters, first is the method cy.request supports the following methods -> GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, among others.

Then the URL to request, and finally, the failOnStatusCode equal to false, avoiding our tests failing with other status codes different to 2xx and 3xx. One crucial part is creating an alias for our request to use for the assertions to validate the status code and JSON body or other necessary validations.

Now, let’s create more requests using different methods with cy.request:

Get started with this complete Selenium automation testing tutorial. Learn what Selenium is, its architecture, advantages and more for automated cross browser testing.

Cypress API Testing POST — Code

 cy.request({
                method: 'POST',
                url: `${config.URL}`,
                failOnStatusCode: false,
                'auth': {
                    'bearer':`${config.Bearer_Rest}`
                },
                body: {'name':'Test6 API6', 
                'gender':'male', 
                'email':'test_api6@test.com', 
                'status':'active'}
            }).as('details')
            //Validate status code
            cy.get('@details').its('status').should('eq', 201)
            cy.get('@details').then((response) => {
                let res = response.body
                att1 = res.id
                cy.log(att1)
            })
            cy.get('@details').then((response) => {
                cy.log(JSON.stringify(response.body))
            })

For the code above, we send a ‘POST’ request to create a new user in the ‘gorest’ API route. We assert that the response returns a 201 (Success and a New resource have been created) status code and saves the id for future purposes (UPDATE, DELETE, PATCH). Besides that, we added a few fields for Bearer Authentication and body request to send the data required for the new user.

Cypress API Testing Put and Delete — Code

 cy.request({
               method: 'PUT',
               url: `${config.URL}`+att1,
               failOnStatusCode: false,
               'auth': {
                   'bearer': `${config.Bearer_Rest}`
               },
               body: {'name':'Test API_Update',
               'gender':'female',
               'email':'test_update@test.com',
               'status':'active'}
           }).as('details')
           //Validate status code
           cy.get('@details').its('status').should('eq', 200)
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })



    cy.request({
               method: 'DELETE',
               url: `${config.URL}`+att1,
               failOnStatusCode: false,
               'auth': {
                   'bearer': `${config.Bearer_Rest}`
               },
           }).as('details')
           //Validate response code
           cy.get('@details').its('status').should('eq', 204)
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })

We can notice from the code above that the att1 global variable is part of the URL; as mentioned above, we need previous data to Update or Delete. Also, there is a new status code for our DELETE request; the response returns a 204 (there is no content to send in the response payload body.) Let’s see the execution results for those tests.

As QAs validate a status code 204, we should ask if this is the proper response; a successful response should be 200 (OK) if the response includes an entity describing the status or a 202 (Accepted). But, again, it is up to your current needs.

It’s time to explore the GraphQL part; unlike a REST API, GraphQL requests are all sent to a single endpoint. We can easily use Cypress to fetch all the uses in our GraphQL endpoint. It will look like this:

 cy.request({
                method: 'POST',
                url: `${config.URL4}`,
                failOnStatusCode: false,
                header: {
                    'Accept-Encoding': 'application/json', 
                    'Content-Type' : 'application/json',
                    'bearer': `${config.Bearer_Graph}`
                },
                body: { query: 'query{users {pageInfo {endCursor startCursor hasNextPage hasPreviousPage} totalCount nodes {id name email gender status}}}' }
            }).as('details')
            //Validate status code
            cy.get('@details').its('status').should('eq', 200)
            cy.get('@details').then((response) => {
                cy.log(JSON.stringify(response.body))
            })

As we can notice from the code above, the body request is a query; that’s the essential part; GraphQL is a query language for APIs; if we understand our GraphQL schema, we can query and get the desired response.

Run your Playwright test scripts instantly on 50+ browser and OS combinations using the LambdaTest cloud.

Cypress plugin API

In this section of our Cypress API testing guide, we will discuss one API plugin, and probably, one of the most useful, related to APIs, cypress-plugin-api; the creator of this plugin mentions that if we merge Postman with Cypress, we obtain the cypress-plugin-api. First, we need to install it.

 'npm i cypress-plugin-api'.

As we are using the 9.7.0 version, we need to add it to our /support/index.js file:

 import 'cypress-plugin-api'

We can now use the cy.api() command. It works precisely like cy.request() command, but in addition to calling the API, it will print our information about the API call in your Cypress runner, as you can see below:

As we can see, the information printed looks useful, including response, headers, and cookies; besides that, we can see the body request and authentication.

Code Walkthrough:

import config from './config.json'
    import { faker } from '@faker-js/faker'
    describe('API Testing ', function () {
       let att1
       let att2  

       it('API - GET details', () => {
           cy.request({
               method: 'GET',
               url: `${config.URL}`,
               failOnStatusCode: false,
           }).as('details')
           //Validate status code
           cy.get('@details').its('status').should('eq', 200)
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })
       })

       it('API - POST Request', () => {
           cy.request({
               method: 'POST',
               url: `${config.URL}`,
               failOnStatusCode: false,
               'auth': {
                   'bearer': `${config.Bearer_Rest}`
               },
               body: {'name':faker.internet.userName(),
               'gender':'male',
               'email':faker.internet.email(),
               'status':'active'}
           }).as('details')
           //Validate status code
           cy.get('@details').its('status').should('eq', 201)
           cy.get('@details').then((response) => {
               let res = response.body
               att1 = res.id
               att2 = res.user
               cy.log(att1)
           })
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })

       })

       it('API Post - POST Request', () => {
           cy.request({
               method: 'POST',
               url: `${config.URL2}`,
               failOnStatusCode: false,
               'auth': {
                   'bearer': `${config.Bearer_Rest}`
               },
               body: {'user':att2,
               'user_id': att1,
               'email':faker.internet.email(),
               'title':'This is a title',
               'body': 'This is a message'}
           }).as('details')
           //Validate status code
           cy.get('@details').its('status').should('eq', 201)
           cy.get('@details').then((response) => {
               let res = response.body
               let post_id = res.id
               cy.log(post_id)
           })
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })

       })

       it('API - PUT Request', () => {
           cy.request({
               method: 'PUT',
               url: `${config.URL}`+att1,
               failOnStatusCode: false,
               'auth': {
                   'bearer': `${config.Bearer_Rest}`
               },
               body: {'name':faker.internet.userName(),
               'gender':'female',
               'email':faker.internet.email(),
               'status':'active'}
           }).as('details')
           //Validate status code
           cy.get('@details').its('status').should('eq', 200)
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })

       })

       it('API - DELETE Request', () => {
           cy.request({
               method: 'DELETE',
               url: `${config.URL}`+att1,
               failOnStatusCode: false,
               'auth': {
                   'bearer': `${config.Bearer_Rest}`
               },
           }).as('details')
           //Validate response code
           cy.get('@details').its('status').should('eq', 204)
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })


       })

    })

Let’s start defining our config.json file; here, we can include some data and URLs:

{
       "URL": "https://gorest.co.in/public/v2/users/",
       "URL2": "https://gorest.co.in/public/v2/posts/",
       "URL3": "https://pokeapi.co/api/v2/pokemon/",
       "URL4": "https://gorest.co.in/public/v2/graphql",
       "Bearer_Rest": "e2360bb230c2fc83af7451f8346d9fcdb699879e3a8f14462a2187f9d670675e",
       "Bearer_Graph": "3df84f0ba9a2028aa6efe7519e3d73466cb301501858acabaad74119082f3b02"
    }

Then, we use ‘faker’ for our random data related to our POST and PUT methods; we can install it using the following:

 npm install --save-dev @faker-js/faker

After that, we use a global variable for our user-id field; it’s up to you if you want to use Cypress env variables or global variables, in my particular case, as this will be used for API. There is no need to use it outside this file; I prefer that variable.

it('API Post - POST Request', () => {
           cy.request({
               method: 'POST',
               url: `${config.URL2}`,
               failOnStatusCode: false,
               'auth': {
                   'bearer': `${config.Bearer_Rest}`
               },
               body: {'user':att2,
               'user_id': att1,
               'email':faker.internet.email(),
               'title':'This is a title',
               'body': 'This is a message'}
           }).as('details')

Regarding the API tests, we added one more test about Post using a user previously created; as we can notice, the API Post — POST Request‘. The structure is similar to our previous request, only changing the body. Testers must understand the API definition to send requests and adequately create Negative tests based on API schema.

It’s time to run our tests; as we saw above, we can run using the UI Runner or terminal mode; let’s try both.

We are going to use the following command to run one specific test spec:

  npx cypress run --spec cypress/integration/test.api.spec.js

As we can see above, the specific test case is executed on the CLI using the “–spec” option.

Mochawesome is also available if we want to take a look:

If you want to know more about Mochawesome, please visit the blog on generating Mocha Reports with Mochawesome. Also, please download the GitHub repo and provide some feedback.

In this tutorial, learn what is Regression testing, its importance, types, and how to perform it.

Cleaner Methods for our Cypress API Testing

As we can see in our code, we are repeating our code multiple times, especially for the POSTs and PUT, GET and DELETE; what about using some methods to encapsulate our “cy.requests” calls:

export default class MainMethods {

       static GetDelMethod(url,method){
           cy.request({
               method: method,
               url: url,
               failOnStatusCode: false,
               'auth': {
                   'bearer': `${config.Bearer_Rest}`
               },
           }).as('details')

       }

Now, let’s reuse the methods inside of our Test code:

it('API - GET details', () => {

           MainMethod.GetDelMethod(`${config.URL}`,'GET')
           //Validate status code
           cy.get('@details').its('status').should('eq', 200)
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })
       })

    it('API - POST Request', () => {
           const body = {'name':faker.internet.userName(),
                   'gender':'male',
                   'email':faker.internet.email(),
                   'status':'active'}
           //Method
           MainMethod.PostMethod(`${config.URL}`, JSON.parse(JSON.stringify(body)))
           //Validate status code
           cy.get('@details').its('status').should('eq', 201)
           cy.get('@details').then((response) => {
               let res = response.body
               att1 = res.id
               att2 = res.user
               cy.log(att1)
           })
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })

       })

    it('API - DELETE Request', () => {
           MainMethod.GetDelMethod(`${config.URL}`+att1,'DELETE')
           cy.get('@details').its('status').should('eq', 204)
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })    
       })

What we tried above was a crude attempt to use the Builder pattern, as the focus here is that the instance is returned from every method (every computation) and is then used to build up the complex object. The builder pattern can help us to reuse and maintain different API test scenarios. You can learn more about it through this blog on Fluent Interface Design Pattern blog.

Using LambdaTest Rest API to validate data

In this section of our blog on Cypress API testing, we will use LambdaTest REST APIs for related APIs to validate the data already uploaded in our previous tests to LambdaTest.

LambdaTest Cypress cloud grid offers an online device farm with 3000+ real devices and browsers to help you get the job done. This can help improve the overall test coverage of an application by enabling tests to be run on different combinations of browsers and operating systems using the same test scripts.

With Cypress parallel testing, run multiple tests concurrently to expedite the testing process and enable Cypress test automation at scale. By leveraging cloud grids and parallel testing, it is possible to significantly improve the quality of a product by thoroughly testing it across a wide range of environments.

Subscribe to the LambdaTest YouTube channel for tutorials around Selenium testing, Playwright browser testing, Appium, and more.

For this example, we will use the Cypress level GET request for execution on the LambdaTest platform. Let’s code one test and get the Cypress console logs from the LambdaTest API endpoint:

 static GetDelMethodLam(url,method){
           cy.request({
               method: method,
               url: url,
               failOnStatusCode: false,
               'headers' : {
                   'accept': 'application/octet-stream',
                   'content-type': 'application/x-gzip',
                   'Authorization': "Basic <code>
               },

           }).as('details')

Let’s dig into the code; we are reusing one of our Methods for ‘GET’ and ‘DELETE,’ just updating the headers part as we need that to authenticate into LambdaTest API.

Once in our test, we use our config.json file for the URL endpoint and testID, passing the Method name and running it to see the data. It is essential to get the test_Id from our LambdaTest:

 import config from './config.json'
    import MainMethod from '../builder/components/Mainmethods'
    describe('API Testing LambdaTest ', function () {

       it.only('API - GET details', () => {

           MainMethod.GetDelMethodLam(`${config.URLL}`+`${config.testId}`+'/console','GET')
           //Validate status code
           cy.get('@details').its('status').should('eq', 200)
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })
       })
    })

As we can see in the response, there are some logs for the past execution of Cypress UI testing.

Another Test example using API for Network logs:

 it('API - GET Network', () => {

           MainMethod.GetDelMethodLam(`${config.URLL}`+`${config.testId}`+'/network','GET')
           //Validate status code
           cy.get('@details').its('status').should('eq', 200)
           cy.get('@details').then((response) => {
               cy.log(JSON.stringify(response.body))
           })
       })

Last but not least, a PATCH method to change the build name:

 static PatchMethodLam(url){
           cy.request({
               method: 'PATCH',
               url: url,
               failOnStatusCode: false,
               'headers' : {
                   'accept': 'application/json',
                   'Authorization': "Basic <>
               },
               body: { 'name': 'cypress - api mod2 cypress' }

           }).as('details')
       }

Shown below is the test runner results:

Hopefully, this will give you an idea of how to take advantage of the LambdaTest APIs and build your Cypress requests.

If you want to deepen your understanding of Cypress and become proficient in using it to test web applications, this course could be a good fit. It covers the fundamentals of Cypress and provides a solid foundation for building more advanced testing skills.

The Cypress 101 certification course is designed for developers and testers who already have a basic understanding of Cypress and want to advance their knowledge and Cypress e2e testing skills.

A complete Selenium WebDriver tutorial that covers what WebDriver is, its features, architecture and best practices.

Wrapping Up

API testing is a process that involves three steps:

Sending the request with the necessary input data
Getting the response’s output data
Validating the response against the expected outcome

These steps seem very easy and quick to follow for any tester and are, in fact, truly easy for low functionality levels, but tests get more and more complex as you start testing APIs on a deeper level.

It is strongly advised to consider Cypress API testing as a core requirement of your project development process and make it as extendable, reusable, and maintainable as possible. With this blog post on Cypress API Testing, we’ve covered a lot, but we’ve only scratched the surface of API Test Automation. The Cypress site has much more detailed documentation and examples of the power of Cypress.

If there are any questions or ideas about improving our Cypress API Testing, please let me know or reach me directly.

Happy Bug Hunting!

How To Run Cypress Tests In Jenkins Pipeline [Jenkins and Cypress Tutorial]

enriquee20 — Wed, 12 Oct 2022 11:07:39 +0000

Cypress is one of the fast-growing test automation frameworks. As you learn Cypress, you will probably come across the need to integrate your Cypress tests with your CI environment. Jenkins is an open-source Continuous Integration (CI) server that automates your web applications’ build and deploys process. By running your Cypress test suite in Jenkins, you also automate testing as part of the build process.

Adding LambdaTest to the formula, you can run your apps across different OS and browser combinations. In this Jenkins and Cypress tutorial, we will dive deep into integrating the Jenkins pipeline with LambdaTest’s Cypress Cloud.

So, let’s get started.

Advantages of Jenkins

Jenkins is a widely popular Continuous Integration (CI) tool. It is free-to-use, open-source software written in Java. Jenkins allows boosting your release agility by providing Continuous Integration services. You can trigger these services by a web application server or simply using a command line to hasten the deployment pipeline & release migration activities. In addition, Jenkins’s popularity offers thousands of plugins to fast-track your productivity.

Detailed down are some of the significant advantages of using Jenkins:

Jenkins is open-source and free to use. It is a preferred CI tool by early-stage startups and large corporations since it has been under development for a long time.
It is a rich plugin ecosystem. At the time of this blog post, there were close to 1500+ plugins available for use.
Jenkins can be integrated with popular cloud platforms such as Amazon EC2, Google Cloud, VMWare vSphere, Digital Ocean, and more.
Anyone can write the tests to detect the errors in their code as soon as possible. So the developers don’t waste time on large-scale error-ridden integrations.
Issues are detected and resolved almost immediately, which keeps the software in a state where it can be safely released at any time.
Most of the integration work is automated. Hence fewer integration issues. It saves both time and money over the lifespan of a project.

If you are new to Jenkins and wish to learn more about it, you can go through this Jenkins tutorial that covers what is Jenkins and how & why to use it.

In the next section of this Jenkins and Cypress tutorial, we will look into why Cypress Jenkins is the right option for your team.

Automate Cypress cloud tests and perform browser automation testing with LambdaTest. Our cloud infrastructure has 3000+ desktop & mobile environments. Try for free!

Why Cypress and Jenkins?

Cypress is an open-source, full-featured, and easy-to-use testing framework for end to end testing. Currently, Cypress is preferred by front-end developers and automation testers who know JavaScript. We can install Cypress using NPM. Also, we don’t need to install any additional libraries, dependencies, drivers, servers, etc., as we have to do in the case of Selenium.

As mentioned above, Jenkins is the predicted option of many startups and large companies trying to accomplish Continuous Integration. It offers a significant plugin ecosystem plus easy configuration with Jenkins; if you are looking for an open-source CI tool that is easy to configure with Cypress, then Jenkins is the right option for your team.

In the next section of this tutorial Jenkins and Cypress tutorial , we will learn how to configure Jenkins to run Cypress tests.

Configuring Jenkins to run Cypress tests

We are going to need NodeJS to execute Cypress. In this section of this Jenkins and Cypress tutorial, we will learn how to install NodeJS in our Jenkins environment. However, before this, you must install Cypress. You can go through this blog on getting started with Cypress to install Cypress on the local machine.

In Jenkins, go to Manage Jenkins > Manage Plugins > Available Plugins and search for NodeJS Plugin and install it.
After you successfully install the NodeJs Plugin, we need to add NodeJs to it. Go to Manage Jenkins > Global Tool Configuration and click Add NodeJS. Then,

Provide a name for your NodeJS installation Eg: Node14.
Hit the Install automatically.
Choose a cypress-compatible NodeJS version.
Add Cypress for Global npm packages to install.
We can keep the other configurations as it is.

Now we need to create your Cypress Jenkins project. First, we must keep things simple; let’s use a freestyle project; as a freestyle, we can break down our build job into several smaller build steps, making it more comfortable to manage builds in separate stages. E.g., in one step, a build might run a suite of functional tests and then tag the build in a second step if all available tests are successful.

A Jenkins freestyle project can be as powerful and complicated as any build job built with a Jenkins pipeline or a Groovy DSL. The drawback to freestyle projects is that the user must know how to script all these actions, and developers must learn how to manage these scripts.

In Jenkins, click New Item, provide a project name, and choose Freestyle project.
As we have our Git project in Source Code Management, add your Git URL and credentials for this Jenkins and Cypress tutorial. If you do not use Git, I encourage you to try it. Git is lightning fast; we’re talking about only a few seconds per command; it quickly adds to your work day. Remember that a large community often is an advantage because an ecosystem revolves around the system.
Now we need to switch to the build environment section. Here we will find and select the option, Provide Node & npm bin/ folder to PATH.
If you remember, we added a NodeJS installation before. We will see the name we provided in the NodeJS Installation dropdown. Choose it, and then we can keep the other configurations.

We are all set; don’t forget to add our Cypress command to execute the script.

Configuring the Jenkins Pipeline

A pipeline is a series of events or tasks interconnected in a particular order. In plain English, a Jenkins pipeline is a set of modules or plugins which enable the implementation and integration of Continuous Delivery pipelines within Jenkins.

The Jenkins pipeline has an expandable automation system for building basic or complex “template” distribution pipelines via the Domain-specific language (DSL) used in the Pipeline. For example, stages in the Declarative Pipeline may have a stages section containing a list of nested stages to be run in sequential order.

The concepts in Jenkins pipelines are as follows:

*Pipeline *— It is code executed for the build, test, and delivery of the applications and is a set of instructions in the state of code for continuous delivery.
Node — It is a machine or system on which Jenkins runs. A node block is a pipeline syntax scripted.
Stage — Here, we can picture the process of Jenkins pipelines. It consists of a series of steps: build, test, and deploy. In earlier versions of Declarative Pipeline, the only way to run chunks of Pipeline code in parallel was to use the parallel step inside the steps block for a stage).
Step — It is a single step in the stage; for example, either build or test or deploy from a single step.

The Jenkins pipeline’s main advantages are automating many tasks and making the CI/CD pipeline tasks reliable, efficient, repeatable, and high in quality.

We can find the Jenkins file for the Pipeline as follows for this Jenkins and Cypress tutorial:

pipeline {
   agent any

   tools {nodejs "Node12"}

   environment {
       CHROME_BIN = '/bin/google-chrome'

   }

   stages {
       stage('Dependencies') {
           steps {
               sh 'npm i'
           }
       }
       stage('e2e Tests') {
         Parallel{
             stage('Test 1') {
                  steps {
                sh 'npm run cypress:ci'
                  }
               }

             stage('Test 2') {
                  steps {
                sh 'npm run cypress2:ci'
                  }
               }

       }
       stage('Deploy') {
           steps {
               echo 'Deploying....'
           }
       }
   }
}

1- Create a new project for Pipeline by going to Jenkins –> New Item. Jenkins -> Select the Pipeline.

2- Scroll down to Pipeline Options. And update according to your Git repo.

3- Our Jenkins file will contain our configuration, and then we can see our results.

So far, we have seen how to configure the Jenkins pipeline. In the next section of this Jenkins and Cypress tutorial, we will deep-dive into integrating your Cypress Jenkins pipeline with the Cypress cloud grid.

How to integrate your Cypress Jenkins Pipeline with Cypress cloud grid?

Jenkins Pipeline, also called “Pipeline,” presents a suite of plugins to assist in integrating our continuous delivery pipeline into Jenkins. Jenkins Pipeline does so with the help of Pipeline DSL (Domain Specific Language) syntax that facilitates easy modeling of even the most complex delivery pipeline.

Configuring your Jenkins Pipeline with LambdaTest

Follow these steps to configure LambdaTest with Jenkins:

Jenkins 2.X or the latest version.
A Jenkins User with root access.
LambdaTest Authentication Credentials.
Keep an eye on your LambdaTest authentication credentials, i.e., your LambdaTest username and access key. You need to set them up as your environment variables. You can retrieve them from your LambdaTest Automation Dashboard by clicking on the key icon around the help button.

This Cypress test automation tutorial will help you learn the benefits of Cypress automation, and how to install Cypress and execute Cypress automation testing over scores of browsers and operating systems online.

Setting up Jenkins

In this section of this Jenkins and Cypress tutorial, we will look into the steps to set up Jenkins.

pipeline {
   agent any

   tools {nodejs "Node12"}

   stages {
       stage('Dependencies') {
           steps {
               sh 'npm i'
               sh 'npm install lambdatest-cypress-cli'
           }
       }
       stage('e2e Tests') {
           steps {
               sh 'npm run cypress:lambda'
           }
       }
       stage('Deploy') {
           steps {
               echo 'Deploying....'
           }
       }
   }
}

1- Create a new project for Pipeline by going to Jenkins –> New Item. Jenkins -> Select the Pipeline.

2- Scroll down to Pipeline Options. And update according to your Git repo.

3- Our Jenkinsfile will contain our configuration:

4- The “cypress:lambda” task will be executed by the “e2e Tests” step in the Jenkins pipeline. So now we can press the “Build Now” button in Jenkins and get the following result:

5- When checking the console output of the build, we can verify that the Cypress tests ran.

As we can notice from the image above, our build was successfully executed, and the tests were uploaded to our LambdaTest Dashboard.

In the following section of this Jenkins and Cypress tutorial, we will learn how to perform parallel testing on Cypress cloud.

How to perform Cypress parallel testing on a cloud grid?

We can use a Cypress cloud grid like LambdaTest, which provides automated cross browser testing on 40+ browsers and operating systems, and Cypress parallel testing to expedite the test execution and help perform our Jenkin pipelines. In addition, it will help improve our overall test coverage by resulting in better product quality, as we can cover different combinations using the same test scripts.

You can also Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around automated browser testing, Cypress testing, CI/CD, and more.

To get started with Cypress e2e testing, follow the below-mentioned steps:

2- Install LambdaTest Cypress CLI on your machine. Trigger the following command to install the same:

npm install -g lambdatest-cypress-cli

2- After installation is completed, set up the configuration using the below command:

lambdatest-cypress init

3- Once the command is completed, lambdatest-config.json is created in the project folder. Next, enter the LambdaTest credentials from the LambdaTest Profile Section.

"lambdatest_auth": {
      "username": "<Your LambdaTest username>",
      "access_key": "<Your LambdaTest access key>"

4- Here is how you can configure the required browser & OS combinations in lambdatest-config.json:

{
  "lambdatest_auth": {
     "username": "",
     "access_key": ""
  },
  "browsers": [
     {
        "browser": "MicrosoftEdge",
        "platform": "Windows 10",
        "versions": [
           "latest"
        ]
     },
     {
        "browser": "Chrome",
        "platform": "Windows 10",
        "versions": [
           "latest"
        ]
     },
     {
        "browser": "Firefox",
        "platform": "Windows 10",
        "versions": [
           "latest"
        ]
     }
  ],

5- The run_settings section in the JSON file contains the desired Cypress test suite capabilities, including Cypress_version, build_name, number of parallel sessions, etc.

"run_settings": {
     "cypress_config_file": "cypress.json",
     "build_name": "build-Cypress-test",
     "parallels": 5,
     "specs": "./cypress/integration/e2e_tests/*.spec.js",
     "pluginsFile": true,
     "ignore_files": "",
     "npm_dependencies": {
        "cypress": "9.0.0",
        "[@cypress](http://twitter.com/cypress)-audit/pa11y": "^1.3.0",
        "cypress-plugin-snapshots": "^1.4.4",
        "cypress-visual-regression": "^1.6.2"
     },
     "feature_file_suppport": true
  },

6- Tunnel_settings in the JSON file lets you connect your local system with LambdaTest servers via an SSH-based integration tunnel. Once this tunnel is established, you can test locally hosted pages on all the browsers currently supported by Cypress on LambdaTest.

"tunnel_settings": {
    "tunnel": false,
    "tunnelName": null
}

Using LambdaTest, we can run our tests in parallel and reduce execution time. Instead of running tests one by one in sequence, parallel testing allows for running multiple tests simultaneously. In addition, this approach executes tests on various browsers, devices, and operating systems parallelly.

Without Cypress Cloud Grid (Compare e2e Tests timing):

Using Cypress Cloud Grid and running multiple OS and Browsers (Compare e2e Tests timing):

To view test performance metrics, navigate to the LambdaTest Analytics Dashboard. The Test Overview will provide a snapshot of tests consistent with stable behavior. You can see all test results, their status, and the overall number of tests passed or failed in both failures and failures’ breakdowns areas.

If you’re a developer or a tester, Cypress 101 certification will prepare you to write tests faster and with greater confidence. You’ll learn the fundamentals of Cypress end to end testing and walk away with a clear understanding of how to write better tests with this Jenkins and Cypress Tutorial.

This Cypress automation testing tutorial will help you learn the benefits of Cypress automation, and how to install Cypress and execute Cypress automation testing over scores of browsers and operating systems online.

Jenkins and Cypress Tutorial: Final Thoughts

Lastly, in this Jenkins and Cypress Tutorial we have covered Jenkins’s importance and how it can be integrated with our Cypress projects to run our tests efficiently and achieve the goal of continuous integration. Using Jenkins to run our tests is time effective, and the results can be visualized with complete logs. It helps fulfill the entire software development life cycle, from development, deployment, testing, monitoring, and releasing.

Jenkins supports various plugins for achieving the project requirements. It also keeps alerting the user via emails regarding the build’s stability. Thanks for reading through this Jenkins and Cypress tutorial.

Happy Bug Hunting!

How To Perform Cypress Accessibility Testing

enriquee20 — Tue, 11 Oct 2022 13:12:53 +0000

Accessibility means designing products, devices, services, vehicles, or environments so that they’re accessible to specially-abled people. A big part of the concept is to enable people with disabilities through assistive technologies (screen readers, keyboard detection, and other assistive technology).

To create accessible things means to create something that is accessible to all (whether they have a disability or not). Users can use an application to achieve established goals with effectiveness, efficiency, and convenience and not be confused with accessibility, which is how users can use an application in a specified context.

The legal argument can be used as the main reason to care about accessibility. In many countries, lack of accessibility has been seen as discrimination against those unable to access the applications. Therefore, it is essential to take the legal aspects seriously and make the application accessible to all users. And this is why accessibility testing is important.

Testers can leverage accessibility testing tools to test a variety of websites and web applications. Automating Accessibility tests allows testers to save time and effort and ship products with quality and confidence. Among all the automation testing frameworks available, Cypress automation framework reduces complexity by offering an all-inclusive testing platform (FrontEnd, BackEnd, Accessibility, Performance Testing) rather than requiring you to select and piece together individual libraries for end-to-end testing.

In this accessibility testing tutorial, we will learn the importance of accessibility testing and how to perform Cypess accessibility testing on a cloud grid.

So, let’s get started!

The importance of Accessibility Testing

The success of an application depends on whether everyone can achieve their goals through their chosen technologies.

We must test an interface against a set of guidelines if we want to be considered for accessibility testing. Common issues that the WCAG doesn’t cover may be considered as well. If you have an accessibility policy, it is good to test your site against its criteria. There are a lot of broad use cases that are covered by the WCAG 2.1 criteria.

Accessibility testing should be focused on the application’s actual use. There are a lot of reasons why a product might not be accessible. It can be a problem with the software itself or how it was designed. Testing for accessibility is about the user and what they want to do. If you create a feature that does not help a user accomplish a task, you need to ask yourself: “Why not?”. Accessibility testing is about making sure a product works for everyone.

In this article, we take a look at some aspects of simulation and discuss some ways through which we can use ios emulator for pc.

Is it possible to automate Accessibility Testing?

Accessibility testing is an essential part of quality assurance, and there are many different ways of conducting it. Unfortunately, exploratory testing for people with impairments is only one of many options, and sometimes it’s necessary to use other accessibility testing tools.

Test websites against criteria; many modern testing tools help companies like ours. For example, you can use a keyboard or screen reader that people with disabilities commonly use. Axe or Google Lighthouse are browser extensions that can run accessibility checks.

Axe-Core is the most common tool for automated accessibility testing in your software development process. Numerous projects are built on top of the Axe-Core; if you use Selenium, WebdriverIO, Cypress, or another automated testing framework, you can implement Axe in your tests.

We want to try new things in this article on Cypress accessibility testing, so I would like to share my new finding, pa11y, a powerful tool for accessibility testing.

Pally and Cypress Accessibility Testing

Firstly, let’s talk about Pally, a command-line interface that loads web pages and highlights any accessibility issues it finds. Second, Pa11y is an automated accessibility testing tool. It runs accessibility tests on your pages via the command line so that you can automate your testing process(Pa11y is licensed under the Lesser General Public License (LGPL-3.0-only).

Now, let’s focus on Cypress and Pally and follow the below-mentioned steps for performing Cypress accessibility testing:

1- Install the dependency in our local project using the below command:

npm install --save-dev [@cypress](http://twitter.com/cypress)-audit/pa11y

2- The following configuration allows Lighthouse and Cypress to make their verifications inside the same browser (controlled by Cypress) instead of creating a new one. In the cypress/plugins/index.js file, let’s add the following:

const { pa11y, prepareAudit } = require("[@cypress](http://twitter.com/cypress)-audit/pa11y");

module.exports = (on, config) => {
  on("before:browser:launch", (browser = {}, launchOptions) => {
    prepareAudit(launchOptions)
  })

on("task", {
    pa11y: pa11y(), // calling the function must be important
  })
}

3- Once we add the following line in the cypress/support/commands.js file, you will be able to use cy.pa11y inside your Cypress tests:

import "[@cypress](http://twitter.com/cypress)-audit/pa11y/commands"

4- Now, we are ready to evaluate some web pages for accessibility; let’s use the following example:

describe('Accessibility Testing Cypress', () => {
   before(function(){
       cy.visit(`${config.URL2}`)
   })

   it('verify full Home Page is displayed correctly', () =>{

       cy.pa11y()   
   })

5- And then let’s run it using npx cypress open.

As we identified from the image above, it displays some errors; more specifically, 36 accessibility violations were found.
As we identified from the image above, it displays some errors/violations; more specifically, 33 accessibility violations were found. We can see more details related to all the rules here.
The only violation is color contrast; text elements must have sufficient color contrast against the background; as we can see, 33 elements are not following that rule.

Code Walkthrough

import config from './config.json'
import MainPage from '../../page-objects/components/MainPage'

describe('Accessibility Testing Cypress', () => {
   before(function(){
       cy.visit(`${config.URL2}`)
   })

   it('verify full Home Page is displayed correctly', () =>{

       //Using Pally as our tool for Accessibility Testing
       cy.pa11y()
   })

it('Verify a search in Google', () => {

cy.origin(`${config.URL3}`, () => {
           cy.visit('/')
       })   
       MainPage.searchGoogle('Accessibility Testing')
       cy.pa11y()

})

})

Let’s start defining our config.json file; here, we can include some data and URLs:

{
   "URL1": "[https://www.lambdatest.com/blog/](https://www.lambdatest.com/blog/)",
   "URL2": "[https://www.scope.org.uk](https://www.scope.org.uk)",
   "URL3": "[http://www.google.com](http://www.google.com)"
}

After that, we need to define our structure; as we can see on the following line of code -> **import **MainPage **from *‘../../page-objects/components/MainPage’*, we want to separate our Cypress locators from our tests, saying that this is the Page Object Model structure. We can find that under the “page-objects” folder:

export default class MainPage {

static searchGoogle(text){
       cy.get(`input[role='combobox']`).type(`${text} {enter}`)
   }
}

As we mentioned above, our methods and locators can be found here; in our example, we try to do a simple search on Google.

describe('Accessibility Testing Cypress', () => {
   before(function(){
       cy.visit(`${config.URL2}`)
   })

For this case, we are using a before() hook that will open up our page before all of our tests, and after that, we can notice two tests, one related to a full-page home validation and the second one for the google search validation.

it('verify full Home Page is displayed correctly', () =>{

       //Using Pally as our tool for Accessibility Testing
       cy.pa11y()
   })

it('Verify a search in Google', () => {

cy.origin(`${config.URL3}`, () => {
           cy.visit('/')
       })   
       MainPage.searchGoogle('Accessibility Testing')
       cy.pa11y()

})

You can go through the following video from the LambdaTest YouTube channel to learn more about Cypress hooks:

You can subscribe to the channel and get the latest tutorials around Cypress testing, automated browser testing, CI/CD, and more!

And here is the test execution, which indicates that our Cypress accessibility testing approach is working:

One thing I forgot to mention during our test using “cy.origin” to use this experimental command, we must enable it from our cypress configuration file; our file must be as follows:

"e2e": {
    "experimentalSessionAndOrigin": true
  },

If we don’t enable it, Cypress will throw an error:

We must upgrade to Cypress 9.6.0, then we can try out the new functionality by setting the new experimentalSessionAndOrigin configuration option to true.

In the next section of this tutorial on Cypress accessibility testing, we will learn how to perform accessibility testing on the Cypress cloud grid.

Online mobile emulators online from LambdaTest allows you to seamlessly test your mobile applications, websites,and web apps on mobile browsers and mobile devices.

How to perform Cypress Accessibility Testing on the cloud grid?

We can use a Cypress cloud grid like LambdaTest, which provides automated cross browser testing on 40+ browsers and operating systems, and Cypress parallel testing to expedite the test execution and help perform Cypress testing at scale. In addition, it will help improve our overall test coverage by resulting in better product quality as we can cover different combinations using the same test scripts.

To get started with Cypress e2e testing, follow the below-mentioned steps:

1- Install LambdaTest Cypress CLI on your machine. Trigger the following command to install the same:

npm install -g lambdatest-cypress-cli

2- After installation is completed, set up the configuration using the below command:

lambdatest-cypress init

3- Once the command is completed, lambdatest-config.json is created in the project folder. Next, enter the LambdaTest credentials from the LambdaTest Profile Section.

"lambdatest_auth": {
      "username": "<Your LambdaTest username>",
      "access_key": "<Your LambdaTest access key>"

4- Here is how you can configure the required browser & OS combinations in lambdatest-config.json:

{
  "lambdatest_auth": {
     "username": "",
     "access_key": ""
  },
  "browsers": [
     {
        "browser": "MicrosoftEdge",
        "platform": "Windows 10",
        "versions": [
           "latest"
        ]
     },
     {
        "browser": "Chrome",
        "platform": "Windows 10",
        "versions": [
           "latest"
        ]
     },
     {
        "browser": "Firefox",
        "platform": "Windows 10",
        "versions": [
           "latest"
        ]
     }
  ],

5- The run_settings section in the JSON file contains the desired Cypress test suite capabilities, including Cypress_version, build_name, number of parallel sessions, etc.

"run_settings": {
     "cypress_config_file": "cypress.json",
     "build_name": "build-Cypress-test",
     "parallels": 5,
     "specs": "./cypress/integration/e2e_tests/*.spec.js",
     "pluginsFile": true,
     "ignore_files": "",
     "npm_dependencies": {
        "cypress": "9.0.0",
        "[@cypress](http://twitter.com/cypress)-audit/pa11y": "^1.3.0",
        "cypress-plugin-snapshots": "^1.4.4",
        "cypress-visual-regression": "^1.6.2"
     },
     "feature_file_suppport": true
  },

"tunnel_settings": {
    "tunnel": false,
    "tunnelName": null
}

7- Now that the setup is ready, it’s time to run the tests; remember that our run_settings file displays the parallels field as five once we trigger our execution in parallel without any extra parameter. We must consider that the code used in the earlier test remains unchanged when we use the Cloud Grid.

lambdatest-cypress run

Shown below is the test execution status from the LambdaTest Automation Dashboard.

To view test performance metrics, navigate to the LambdaTest Analytics Dashboard. The Test Overview will provide a snapshot of tests consistent with stable behavior. Meanwhile, the Test Summary will display the total number of tests passed or failed and any completed and pending tests.

If you are a developer or a tester and have a basic understanding of Cypress and want to take your knowledge to the next level, then this Cypress 101 certification course is for you.

Here’s a short glimpse of the Cypress 101 certification from LambdaTest:

Automate Cypress testing and perform browser automation testing with LambdaTest. Our cloud infrastructure has 3000+ desktop & mobile environments. Try for free!

Final Thoughts

It’s important to ensure your website is accessible to all visitors, including those who have disabilities. In this Cypress tutorial, we learned the importance of accessibility testing and how to perform Cypress accessibility testing on a cloud grid.

Let’s include Accessibility Testing in our projects; Accessibility is easy to consider once you start caring about it. The importance here is to embrace accessibility as part of our Automation testing. Let’s keep applications accessible to as many people as possible.

“We must guarantee what we deliver works for everyone.” — Enrique A Decoss

My suggestion to all Testers is to consider accessibility in your test automation projects; we should work together and keep applications available to all. Accessibility can help us to generate a real impact.

Happy Bug Hunting!

How To Avoid Anti-Patterns In Cypress

enriquee20 — Mon, 10 Oct 2022 12:36:49 +0000

No matter how advanced your automation technology is, anti-patterns represent standard bad practices, code smells, and pitfalls. In this case, when creating automated tests, teams can experience a range of difficulties that compound to create inefficient, incomplete, and hard-to-maintain tests.

In addition, to provide high-quality, cost efficiency, and on-time delivery, it’s essential to recognize the signs that your tests aren’t performing optimally. In this Cypress tutorial on avoiding anti-patterns in Cypress, we will discuss some anti-patterns that we believe should be avoided using Cypress test automation framework for the most relevant testing experience and end product.

Let’s get started!

Get the best out of your Cypress tests with LambdaTest’s online Cypress automation tool. Check out how you can test your Cypress testing scripts using LambdaTest’s online cloud.

Fragile Locators

Have you experienced fragile locators in your test scripts? Any slight change on the UI would fail the tests, and it will require some maintenance work to update the specific locator.

Imagine a dynamic CSS, XPath, Id, Class, Tag selectors; it could be tough to target elements changing every time the web page loads.

Let’s imagine an input field

<input class="gLFyf gsfi" jsaction="paste:puy29d;" maxlength="2048" name="q" type="text" aria-autocomplete="both" aria-haspopup="false" autocapitalize="off" autocomplete="off" autocorrect="off" autofocus="" role="combobox" spellcheck="false" title="Search" value="" aria-label="Search" data-ved="0ahUKEwjj1t2JiY32AhVQkmoFHTMfD48Q39UDCAQ">

The easiest way to approach could be using:

cy.get('.a4bIc')

But, that wouldn’t be the best approach as this is a fragile selector; instead, we should add test attributes to our elements, and the example above it should be like the following:

<input class="gLFyf gsfi" jsaction="paste:puy29d;" maxlength="2048" name="q" type="text" aria-autocomplete="both" aria-haspopup="false" autocapitalize="off" autocomplete="off" autocorrect="off" autofocus="" role="combobox" spellcheck="false" title="Search" value="" aria-label="Search" data-ved="0ahUKEwjj1t2JiY32AhVQkmoFHTMfD48Q39UDCAQ" data-test="submit">

Now, we can use our locator in a better way:

cy.get('[data-test=submit]')

The test-cy attribute will not change from CSS style or JS behavioral changes; additionally, it clarifies to everyone that this element is used directly by the test code.

Online Android Emulator for testing your native Android apps and testing web apps over android browsers. Test your native, hybrid, and webapps across all legacy and latest mobile operating systems on most powerful Andoird emulator online.

Overcomplexity, chains in Cypress

We always want to use elegant solutions and apply a better approach in our test automation code, but always remember the KISS principle; if you are not aware, KISS is an acronym for Keep It Simple, Stupid. This principle says about making your code simple. It will help if you avoid unnecessary complexity. A simple code is easier to maintain and easier to understand.

cy.get(nice.selector-unique').type('This is a great blog post.')

Chaining the .type() onto the cy.get(), telling it to type into the subject yielded from the cy.get() command, which will be a DOM element.

it('Another example of Command chains', () => {
  cy.visit('[https://www.awesomesite.com'](https://www.awesomesite.com'))

cy
  // Find the element with id any-link'
  .get('#any-link')
  .as('myElement') // sets the alias
  .click()

cy.get('[@myElement](http://twitter.com/myElement)') // re-queries the DOM as before (only if necessary)
  .click()

})

Using Aliases, let us reuse our DOM queries for faster tests when the element is still in the DOM. Furthermore, it automatically handles re-querying the DOM when it is not immediately found in the DOM. It is beneficial when dealing with front-end frameworks that do a lot of re-rendering.

Another cool thing about Cypress is the built-in retry function available in too many commands; there is a default timeout set to 4000 milliseconds, which you can modify in your cypress.json file. If you come from Selenium, you probably know it as a fluent wait. In this case, nothing extra needs to be added to our tests to make them wait fluently.

Inefficient waits, avoiding waits in Cypress

Perhaps, you want to debug your tests, or you need to halt your tests for a couple of seconds to see the desired state. But, in Cypress, when you use .wait() and do nothing for a couple of seconds, how long do we need to wait? We understand sometimes our test scripts are going so fast that we need to consider hard waits and tell Cypress to reduce speed. But remember using waits in our code is regarded as an anti-pattern in Cypress.

cy.get('#any-link')
    .wait(5000) 
    .click()

Instead, we can use timeout per command; the timeouts can be modified per command, which will affect all default assertions and any assertions chained after that command.

cy.get('#any-link', {timeout: 5000})
    .should('be.visible')
    .click()

Also, you can wait for basically anything by passing a callback function into the .should() command. It will use the built-in retry logic and wait for the procedure to pass. As a recap in our example above, Cypress will wait 5 seconds for the element to exist in the DOM and wait another 5 seconds for the same element to be visible.

Optimizing DRY, custom commands in Cypress

If you are not aware of custom commands in Cypress, it is an excellent time to avoid reinventing the wheel and reuse those available custom commands. Cypress comes with its API for creating custom commands and overwriting existing commands, for example, cypress-downloadfile:

You can install the module:

npm install cypress-downloadfile

Then, add the following line to cypress/support/commands.js:

require('cypress-downloadfile/lib/downloadFileCommand')

Add the following lines to cypress/plugins/index.js

const {downloadFile} = require('cypress-downloadfile/lib/addPlugin')
module.exports = (on, config) => {
  on('task', {downloadFile})
}

After we can start using the custom command the following way:

cy.downloadFile('[https://my_blog.pdf'](https://my_blog.pdf'), 'downloads', 'blogpost.pdf')

As mentioned before, we can reuse most of the custom commands, but Cypress allows us to modify the behavior of these custom commands; this is really useful to optimize our code and use the DRY principle.

Cypress.Commands.overwrite('download', (url, directory) => {})

Let’s try not to overcomplicate things and reuse custom commands in our tests.

In the below Cypress testing tutorial video, you’ll understand how to create custom commands in Cypress.

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.

Behavior Driven Development in Cypress

Behavior-driven development is a software engineering practice developed to deliver high-quality products by focusing on the business value or behavior of the system. The main difference is BDD focuses on the behavior/ business value. In contrast, TDD focuses on tests which sometimes leads developers to become too detail-focused compared to the business focus/value. However, it’s important to understand the TDD vs BDD difference before choosing a suitable framework.

Let’s start adding the cucumber plugin using npm to our current Cypress project. Please follow the below video for Cypress installation:

Please install the plugin.

npm install --save-dev cypress-cucumber-preprocessor

The following dependency with the latest version will be added to your package.json of the project. At the time of writing this recipe, the version of cypress-cucumber-preprocessor is 4.1.4

devDependencies": { "cypress-cucumber-preprocessor": "^4.1.4" }

To make it work, we would need to add it to cypress plugins as part of Cypress Configuration under cypress/plugins/index.js

const cucumber = required('cypress-cucumber-preprocessor').default

module.exports = (on, config) => {
  on('file:preprocessor', cucumber())

}

Next, we need to add cosmiconfig configuration to the package.json. Cosmiconfig searches and loads the required configuration of the project. In this case, we are defining to locate the step definitions by setting up the below property.

"cypress-cucumber-preprocessor": {
    "nonGlobalStepDefinitions": true
  }

Let’s create a new folder under Cypress -> Integration directory as ‘cucumber-test’ and then create a new feature, “Home.feature.”

Feature: Home / Landing Page

Scenario: Navigating to E-commerce Store
           Given I open home page
           Then I should see Homepage

For step definition location, let’s create a folder named “home.”

Let’s create a step definition file ‘homeSteps.js.”

import { Given } from "cypress-cucumber-preprocessor/steps";

Given('I open home page', () => {
    cy.visit('[https://ecommerce-playground.lambdatest.io/'](https://ecommerce-playground.lambdatest.io/'))
}) 

Then('I should see Homepage', () => {    
    cy.get('#search').should('be.visible')
})

The folder structure should be as the following:

Now, let’s run using the following command in the terminal or command console to execute the test:

npx cypress open

On Cypress Test Runner, select ‘home.feature’

And you should see the results correctly:

Cucumber Expressions

In the “.feature” file, cypress-cucumber-pre-processor uses the same expression as the cucumber expressions to link Gherkin to step definition. This can be achieved either by Cucumber expressions or regular expressions. The advantage of these is that they are more humanly readable than regular expressions. The following is how a Gherkin Step is translated in Step Definition.

Gherkin Step

Given I open home page

Step Definition translation

Given('I open home page', () => { 
cy.visit(url) 
})

*** Test your native, hybrid, and webapps across all legacy and latest mobile operating systems on most powerful Andoird emulator online.***

Gherkin Keywords

Keywords are used to give structure & meaning to the executable specifications. For example, every specification or a feature file starts one of the keywords as:

FEATURE
SCENARIO
SCENARIO OUTLINE
BACKGROUND

Examples:

Feature: Background Example

Background: Given greeting has been set

Scenario: example #1        
  When name is "John"        
 Then greetings equals "Hello John"

Scenario: example #2        
 When name is "Mary"        
 Then greetings equals "Hello Mary"

Step definition will look like the following:

let myName, greeting, finalString;

Given("greeting has been set", () => {    
greeting = 'Hello '
})

When("name is {string}", setName => {    
myName = setName    
finalString = greeting.concat(myName) 
})

Then("greetings equals {string}", expectedValue => {    expect(finalString).to.equal(expectedValue) 
})

Take this certification to showcase your expertise with end-to-end testing using Cypress automation framework and stay one step ahead.

Here’s a short glimpse of the Cypress 101 certification from LambdaTest:

Gherkin Functions

Gherkin uses functions to execute the specifications/ features files. These functions are used to translate the specification to executable tasks with the help of expressions or regular expressions.

**GIVEN **represents pre-conditions in the executable specification. It is a pre-step to the specification or test.
WHEN represents the condition in the executable specification. It is a condition to the specification or test.
**THEN **represents post-condition in the executable specification. It is the post-condition to the specification or test. There could be single or multiple steps as part of Then (post-condition).
**AND **step is to extend pre-step, conditions, and post-condition (s). It can be used with all the functions (Given, When & Then).
**BUT **is helpful to define the negative step in the scenario. Same like AND step, BUT also supports the Given/When/Then step.

How do you write a feature statement?

Follow the following principles to build greatness in features.

Keep it short and to the point.
Make your benefits measurable.
Emphasize the advantages.

The principles are not mandatory like Gherkin Keywords or Function, but they communicate the vision or goal of the feature.

Test your Android Emulator for iOS apps on an official mobile emulators for app testing hosted on cloud. No need to buy every new and expensive mobile devices for native app testing.

Feature and Steps Definition

Here, we can find our Feature File and our Step Definition file.

File: search.feature

File: searchSteps.js

Code Walkthrough

Let’s start defining our Page file, here we can include our locators and URLs:

searchPage.js

const URL = "[https://ecommerce-playground.lambdatest.io/](https://ecommerce-playground.lambdatest.io/)"
const search = "#search"

class SearchPage{
    static visitPage(){
        cy.visit(URL)
    }

static searchPrd(name){
        cy.get(search)
        .type(name+'{enter}')
    }

}

export default SearchPage

We defined the URL, in this case, LambdaTest Playground, and our search locator, as we can see in the following two methods:

class SearchPage{
    static visitPage(){
        cy.visit(URL)
    }

static searchPrd(name){
        cy.get(search)
        .type(name+'{enter}')
    }

Now, let’s take a look into our Step Definition file searchSteps.js.

import { Given, When, Then } from "cypress-cucumber-preprocessor/steps"
import SearchPage from './searchPage'

First, we need to import our Cucumber plugin previously installed and our SearchPage file; this file includes our selectors and methods.

Now we need to define our Given, When, and Then steps; let’s start with the “Given” one:

Given('I open home page', () => {
    SearchPage.visitPage()
})

As we can notice, we are calling our SearchPage method to perform a “cy.visit”.

Related to our “When” definition, we take advantage of dynamic parameters coming from our feature file. Therefore, it is helpful to get the actual search value from the feature file.

Scenario: Navigating to E-commerce and Search Mac Devices
        Given I open home page
        When I search for "Mac"
        Then I should see Product Available



When('I search for {string}', Mac => {    
    SearchPage.searchPrd(Mac)

})

As we notice, we are distinguishing from a search returning any Product vs. a search returning no Products; it is helpful as our feature can include negative scenarios.

Then('I should see Product Available', () => {    
    cy.get(`div:nth-of-type(1) > .product-thumb`)
        .should('be.visible')
})

Then('I should Not see Product Available', () => {    
    cy.get(`div:nth-of-type(1) > .product-thumb`)
        .should('not.exist')
})



Scenario: Navigating to E-commerce and Search Mac Devices
        Given I open home page
        When I search for "Mac"
        Then I should see Product Available

Scenario: Navigating to E-commerce and Search Monitor Devices
        Given I open home page
        When I search for "Printers"
        Then I should Not see Product Available

    Scenario: Navigating to E-commerce and Search Samsung Devices
        Given I open home page
        When I search for "Samsung"
        Then I should see Product Available

And here is the test execution, which indicates that our BDD approach is working:

How to run Regression on Cypress Cloud Grid

We can use a Cloud Cypress Grid like LambdaTest, which provides automated cross browser testing on 40+ browsers and operating systems, and Cypress parallel testing to expedite the test execution in a scalable way. In addition, it will help improve our overall test coverage by resulting in better product quality as we can cover different combinations using the same test scripts.

To get started with Cypress testing, you have to install LambdaTest Cypress CLI on your machine. Trigger the following command to install the same:

npm install -g lambdatest-cypress-cli

After installation is completed, set up the configuration using the below command:

lambdatest-cypress init

Once the command is completed, lambdatest-config.json is created in the project folder. Next, enter the LambdaTest credentials from the LambdaTest Profile Section.

"lambdatest_auth": {
      "username": "<Your LambdaTest username>",
      "access_key": "<Your LambdaTest access key>"

Here is how you can configure the required browser & OS combinations in lambdatest-config.json:

{
  "lambdatest_auth": {
     "username": "",
     "access_key": ""
  },
  "browsers": [
     {
        "browser": "MicrosoftEdge",
        "platform": "Windows 10",
        "versions": [
           "latest"
        ]
     },
     {
        "browser": "Chrome",
        "platform": "Windows 10",
        "versions": [
           "latest"
        ]
     },
     {
        "browser": "Firefox",
        "platform": "macOS Big Sur",
        "versions": [
           "latest"
        ]
     },
     {
        "browser": "Firefox",
        "platform": "Windows 10",
        "versions": [
           "latest"
        ]
     }
  ],

The run_settings section in the JSON file contains the desired Cypress test suite capabilities, including Cypress_version, build_name, number of parallel sessions, etc.

"run_settings": {
      "Cypress_config_file": "Cypress.json",
      "build_name": "build-cucumber-testing",
      "parallels": 5,
      "specs": "./Cypress/integration/cucumber-tests/*.feature",
      "ignore_files": "",
      "feature_file_suppport": false
   },

Tunnel_settings in the JSON file lets you connect your local system with LambdaTest servers via an SSH-based integration tunnel. Once this tunnel is established, you can test locally hosted pages on all the browsers currently supported by Cypress on LambdaTest.

"tunnel_settings": {
    "tunnel": false,
    "tunnelName": null
}

Now that the setup is ready, it’s time to run the tests; remember that our run_settings file displays the parallels field as five once we trigger our execution in parallel without any extra parameter.

lambdatest-cypress run

Shown below is the test execution status from the LambdaTest Automation Dashboard.

Final Thoughts

The presented list was not supposed to be exhaustive since there are good resources and smells/patterns in Parts II and III of xUnit Test Patterns. In this Cypress e2e testing tutorial on avoiding anti-patterns in Cypress, I focused on the BDD approach as our Test Automation must be customer-centric and easy to follow from our non-technical stakeholders.

Happy Bug Hunting with Cypress!

TDD vs BDD: Choosing The Suitable Framework

enriquee20 — Fri, 07 Oct 2022 11:28:47 +0000

Most Software Developers in Test are familiar with Test-Driven Development, or TDD, but Behavior-Driven Development, or BDD, is often misunderstood. The truth is that both of these approaches have advantages and disadvantages to consider.

This blog deep dives into TDD vs BDD comparison by looking at both these approaches individually. Later, we would compare them on functionalities, supported frameworks, and more. I could say BDD is merely the evolution of TDD.

What is Test-Driven Development (TDD)?

Test-Driven Development is a programming practice implemented from a developer’s perspective. In this process, a QA engineer begins designing and writing test cases for every small functionality of an application.

This technique tries to answer a simple question — Is the code valid? The primary purpose of this practice is to modify or write a new code only when the tests fail. Consequently, it results in lesser duplication of test scripts. This technique is mainly popular in agile development ecosystems. In a TDD approach, automated test scripts are written before functional pieces of code.

Check this Cypress automation testing tutorial that will help you learn the benefits of Cypress automation, and how to install Cypress and execute Cypress automation testing over scores of browsers and operating systems online.

How to Implement Test-Driven Development (TDD)

Test-driven development gives preference to testing instead of the implementation phase. As all the tests pass, it signals the end of the first iteration. However, if more features have to be implemented, all the phases must be repeated with new feature tests. The figure below summarizes the flow of TDD:

Pros and Cons of Test-Driven Development (TDD)

TDD is a test-first approach, where automated test scripts are typically written before implementing the product’s actual features. However, TDD has its own share of advantages (or pros) and disadvantages(or cons)

Advantages of Test-Driven Development (TDD)

Reduced cost of Development: The development process in TDD is divided into smaller chunks to simplify the detection of issues at the early stages of design and development.
Focus on design and architecture: Writing tests before the implementation makes the development process more seamless and efficient.
Improved Code Coverage: Through TDD, a well-designed system can achieve 100 percent code coverage.
Code visibility: Tests are written to verify smaller functionalities, making it easy to refactor and maintain the code.
Detailed Documentation: Since tests are written for verifying micro-level functionalities, writing documentation becomes an easy task.

Disadvantages of Test-Driven Development (TDD)

Bugs leading to faulty code: Tests could contain bugs which in turn results in faulty implementation. This can be averted by using the right BDD framework, performing detailed code review, and more.
Costly Architectural mistakes: If the generated test code is not in line with the desired architecture, it could result in huge losses.
Slowness in development: Creating test cases before code development slows product development. In addition, framing test cases may take a huge time as the actual implementation is not available at that time.
Requires prior experience: Prior experience with TDD is a must since many teams commit the mistake of not running tests at the Red Stage.

What is Test-Driven Development (TDD)?

How to Implement Test-Driven Development (TDD)

Pros and Cons of Test-Driven Development (TDD)

Advantages of Test-Driven Development (TDD)

Reduced cost of Development: The development process in TDD is divided into smaller chunks to simplify the detection of issues at the early stages of design and development.
Focus on design and architecture: Writing tests before the implementation makes the development process more seamless and efficient.
Improved Code Coverage: Through TDD, a well-designed system can achieve 100 percent code coverage.
Code visibility: Tests are written to verify smaller functionalities, making it easy to refactor and maintain the code.
Detailed Documentation: Since tests are written for verifying micro-level functionalities, writing documentation becomes an easy task.

Disadvantages of Test-Driven Development (TDD)

**Bugs leading to faulty code: **Tests could contain bugs which in turn results in faulty implementation. This can be averted by using the right BDD framework, performing detailed code review, and more.
Costly Architectural mistakes: If the generated test code is not in line with the desired architecture, it could result in huge losses.
Slowness in development: Creating test cases before code development slows product development. In addition, framing test cases may take a huge time as the actual implementation is not available at that time.
Requires prior experience: Prior experience with TDD is a must since many teams commit the mistake of not running tests at the Red Stage.

In this article on what is TDD vs BDD, we have covered what is TDD, including its advantages and disadvantages. In the next section, we will look into BDD.

What is Behavior-Driven Development (BDD)

Behavioral-Driven Development (BDD) is derived from the Test-Driven Development (TDD) methodology. In BDD, tests are based on systems behavior. BDD approach describes different ways to develop a feature based on its behavior. In most cases, the Given-When-Then approach is used for writing test cases. You can learn more about Gherkin by reading the article on Behavior Driven Development By Selenium Testing With Gherkin.

Let’s take an example for better understanding:

Scenario: User can sign in

Given a valid user with username “lambdatest1.”
When I login as “lambdatest1.”
Then I should see a message “Welcome, lambdatest1”

Here is the overall approach to BDD:

Debugging the errors in the latter stages of the development life cycle often proves to be very expensive. In most cases, ambiguity in understanding the requirements is the root cause behind this. Therefore, one must ensure that all the development efforts remain aligned towards fulfilling pre-determined requirements. BDD allows developers to do the above by:

Allowing the requirements to be defined in a standard approach using simple English.
Providing several ways to illustrate real-world scenarios for understanding requirements.
Providing a platform that enables the tech and non-tech teams to collaborate and understand the requirements

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

How to Implement Behavior-Driven Development (BDD)

As we know, BDD is an extension of TDD. BDD plays a crucial role in cutting back the bugs and errors you would encounter at later stages of product development. Effective test automation strategy, including scenarios, can be developed by involving different teams (e.g., engineering, product management, marketing, etc.).

The BDD approach accords technical and non-technical teams for the collaboration of knowledge and ideas. It’s time for some action.

Cucumber is a tool that supports BDD; anyone can write specifications in plain English using Gherkin. It is as simple as adding a test from the business value point of view, as I like to call business-centric Test Automation. If you are new to Cucumber, you can also check out the step-by-step tutorial on Selenium Cucumber with examples.

Let’s start by adding the Cucumber plugin using npm to our current Cypress Testing project.

1- Please install the plugin.

npm install --save-dev cypress-cucumber-preprocessor

2- The following dependency with the latest version will be added to your package.json of the project. At the time of writing this recipe, the version of cypress-cucumber-preprocessor is 4.1.4

devDependencies": { "cypress-cucumber-preprocessor": "^4.1.4" }

3- To make it work, we would need to add it to cypress plugins as part of Cypress Configuration under cypress/plugins/index.js

    const cucumber = required('cypress-cucumber-preprocessor').default

 module.exports = (on, config) =&gt; {
      on('file:preprocessor', cucumber())
    }

4- Next, we need to add cosmiconfig configuration to the package.json. Cosmiconfig searches and loads the required configuration of the project. In this case, we are defining to locate the step definitions by setting up the below property.

"cypress-cucumber-preprocessor": {
        "nonGlobalStepDefinitions": true
      }

5- Let’s create a new folder under Cypress -> Integration directory as ‘cucumber-test’ and then create a new feature, “Home.feature.”

Feature: Home / Landing Page

    Scenario: Navigating to E-commerce Store
               Given I open home page
               Then I should see Homepage

6- For step definition location, let’s create a folder named “home.” Let’s create a step definition file ‘homeSteps.js.”

 import { Given } from "cypress-cucumber-preprocessor/steps";

    Given('I open home page', () =&gt; {
        cy.visit('[https://ecommerce-playground.lambdatest.io/'](https://ecommerce-playground.lambdatest.io/'))
    }) 

    Then('I should see Homepage', () =&gt; {    
        cy.get('#search').should('be.visible')
    })

The folder structure should be as the following:

7- Now, let’s run using the following command in the Terminal or command console to execute the test:

    npx cypress open

8- On Cypress Test runner, select ‘home.feature.’

And you should see the results correctly:

Note: You can download the code from the GitHub Repository.

Gherkin Keywords

Keywords are used to give structure & meaning to the executable specifications. Every specification or a feature file starts one of the keywords as:

Feature
Scenario
Scenario Outline
Background

Feature — It is the primary key in the Gherkin; it is used to describe the specification name.

Feature: Hello     
    In order to start a conversation with someone     
    chat bot needs to start with greetings     
    so the user gets the interactive feel.

Scenario — It is the collection of actions or steps which need to be performed to fulfill a test objective.

Feature: Greetings     
    In order to start the conversation with someone   
    chat bot needs to start with greetings     
    so the user gets the interactive feel.

    Scenario: example     
    Given greeting has been set to "hello"     
    When name is "Frank"     
    Then greetings equals "Hello Frank"

Scenario Outline — is used when the same scenario needs to be executed with multiple data sets. Scenario Outline is always defined with Examples keyword that’s where data sets can be defined to execute the same scenario multiple times. Scenario Outline is used for Data-driven tests.

Feature: Greetings  
    In order to start the conversation with someone
    chat bot needs to start with greetings   
    so the user gets the interactive feel.

    Scenario Outline: example    
    Given greeting has been set to""    
    When name is ""    
    Then greetings equals "" 
    Examples: 
    | greeting | name | conversation |  
    | Hello      | Frank   | Hello Frank   |  
    | Hi         | Maria   | Hi Maria      |
    | Hey        | Johnny  | Hey Johnny    |

Implementation example:

 let myName, greeting, finalword
    Given("greeting has been set to {string}", setGreeting =&gt; {    
    greeting = setGreeting + ' ' 
    })

    When("name is {string}", setName =&gt; {    
    myName = setName    
    finalString = greeting.concat(myName) 
    })

    Then("greetings equals {string}", expectedValue =&gt; {    expect(finalword).to.equal(expectedValue)
    })

Background — It is used to define a step or series of steps common to all the tests included in the feature file. The steps defined as part of the background get executed before each scenario. Adding the Background section is helpful to avoid duplication of feature steps.

Feature: Background Example 
    Background: 
    Given greeting has been set 
    Scenario: example1        
    When name is "Frank"        
    Then greetings equals "Hello Frank" 
    Scenario: example2        
    When name is "Maria"        
    Then greetings equals "Hello Maria"

Pros and Cons of Behavior-Driven Development (BDD)

BDD is an approach that involves managers, testers, developers, etc., in the whole process. As a result, BDD offers a huge number of benefits. Let’s look at some of the major ones in this section.

Advantages of Behavior-Driven Development (BDD)

Improved Communication: Creating scenarios requires close coordination between clients, managers, developers, testers, etc. This unifies the team in understanding the product behavior.
Reduced cost of Quality Control: Automated acceptance tests are used to depict the scenarios, which in turn helps in reducing the costs involved in inspecting the product quality.
Accurate task estimation: Since the expected behavior is predicted before, there are few chances to change the software application’s architecture.
Better user experience: The scenarios and tests written before development take the user’s perspective into account. The focus is on the desired behavior rather than on implementing features.
Excellent documentation: When a certain test fails, the specification is updated, resulting in the detailed documentation.

Challenges of Behavior-Driven Development (BDD)

Requires more involvement from all the stakeholders: Putting all the people together becomes difficult for teams. Is it the three amigos sitting down together, talking, collaborating, and leaving with a common language around the system requirements?
BDD tools struggle with parallelization: Cucumber and SpecFlow do parallelization or support parallel testing in a sub-optimal manner. They parallelize at the feature file level. It implies that if you want to run 50 tests in parallel, you need to have 50 feature files. That’s a lot of feature files.
Writing incorrect Gherkin syntax: The issue is that most of us do not follow the correct Gherkin syntax as prescribed by the BDD creators. Just remember Given-When-Then steps must appear in order and cannot repeat.

You can go through this webinar if you are intrigued to know more about using the BDD and Online Selenium Grid together.

You can also Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around Selenium testing, Cypress testing, CI/CD, and more.

TDD vs BDD — The Final Showdown

TDD vs BDD is a quest for some developers. Even experienced developers find it difficult to differentiate between these approaches. Now that we have touched upon the working and implementation of TDD and BDD, let’s deep dive into the major differences in this epic TDD vs BDD clash:

Criteria	Test-Driven Development (TDD)	Behavior-Driven Development (BDD)
Language	Test cases designed in TDD are Technical. These are similar to the test cases that are normally written during the testing phase.	The test scenarios designed in BDD are written in simple English language.
Implementation Level	There is a low-level implementation in TDD.	The scenarios are easy to understand and implement, making BDD a high-level implementation with regard to test case development.
Key Stages	Test case development is the major phase in TDD.	Discussion and creation of scenarios are the major stages in BDD.
Stages involved in Development	TDD involves three main stages, Test creation, implementation, and code refactoring are the major stages in TDD.	BDD involves a number of stages like feature discussion, scenario creation, testing, implementation, and code refactoring.
Participants	Only technical teams like development teams take part in TDD processes.	BDD involves many teams, right from client to business analysts, testers, developers, etc.
Primary Focus	Development of required functionality based on test cases is the primary focus in TDD.	BDD focuses on the correspondence between implemented features and expected behavior.
Documentation	TDD requires documentation for the creation of accurate test cases.	Thrust is laid on documentation created during the scenario creation process.
Tools	The tools (or frameworks) used in TDD involve JUnit, TestNG, NUnit, etc. These are used to run test cases.	Gherkin is used for writing scenarios in BDD. Cucumber, SpecFlow, etc., are some of the widely used test automation frameworks.
Applicable Domain	The main focus in TDD is to get appropriate functionality through implementation.	BDD has the defined domain as “Behavior.” This focuses on the product’s behavior at the end of implementing the product functionality.
Bug Tracking	Bug tracking is easier in TDD, as the tests indicate whether they have passed or failed.	Bug tracking in BDD requires integration between multiple tools across the organization.

So, these were the key differences as far as TDD vs BDD is concerned. So, make sure to look upon these differences when you have to decide between TDD vs BDD.

Can TDD and BDD work together?

So far, we have seen what is different as far as TDD vs BDD is concerned. The best part is that these processes are not mutually exclusive. While it’s not unusual for Agile teams to use one without the other, making these two work together can ensure a higher degree of efficiency in testing use cases, thereby bringing confidence in the performance.

TDD, when used alongside BDD, gives importance to web testing from the developer’s perspective, with greater emphasis laid on the application’s behavior. To implement the specifics, developers can create separate testing units to get robust components. This is beneficial since the same component can be used in different places across the software development process.

You can use cloud tools like LambdaTest to leverage the capabilities of both TDD and BDD frameworks and perform live testing. LambdaTest is a cross browser testing platform that enables you to run your test scripts on an online device farm of 3000+ real browsers and real operating systems.

LambdaTest integration with tools like Slack, Microsoft Teams, etc., makes discussions between the teams efficient and easy. TDD or BDD, the choice is governed by the individual needs of an application or the enterprise.

The combination of TDD and BDD frameworks can add more value to the software development process. This is where automation testing tools like LambdaTest can be beneficial since they can be integrated with major TDD and BDD frameworks.

This Playwright Automation tutorial will guide you through the setup of the Playwright framework, which will enable you to write end-to-end tests for your future projects.

TDD vs BDD — Which approach is best for your project?

BDD and TDD have differences and similarities. Although, at the same time, it’s not unusual for Agile teams to use one without the other, making the two work together can guarantee a higher degree of efficiency in testing application use cases, thus obtaining greater confidence in their performance.

TDD vs BDD, an Agile team, alongside TDD, can use the BDD approach to put in place a higher level of testing that takes care of technical nuances from the Agile team’s point of view and assesses the application’s behavior.

To implement the specifics, we can create separate testing units to maintain the robustness of different components. It can be beneficial considering that the same component can be used in other places across an application.

The testing process is based on specifying test scenarios in simple language. Then, Automation Engineers add TDD parts for testing certain specific components. Whether to choose BDD over TDD or use a combination of the two methods is a choice ruled by the needs of an application or organization.

Experimenting with BDD if you’re already doing TDD testing can add value to the Agile process. Using the two together is more accessible, and you don’t need to change or rework the existing approach. All it takes is updating the testing framework to adjust the other.

Selenium 101 certification from LambdaTest is a great way to validate your expertise in Selenium automation testing. There are plenty of good reasons to get Selenium certified. You can use it to prove that you’re on top of things, or you can use it as a way to help yourself learn.

Final Thoughts

In this TDD vs BDD article, you can always view the big picture and decide which approach is best for your software requirements. However, whether you choose to implement test-driven or behavior-driven development, you will require strong QA and testing skills and tools.

Understanding TDD vs BDD approaches work can help Agile teams and other stakeholders improve the development process by zeroing in on the best test strategy for their needs. Then, depending on the nature of the project and the desired result, you can choose between a mix of the two techniques to enhance test coverage efficiency.

Thus, till then, Happy Testing!

Complete Guide To Cypress Visual Regression Testing

enriquee20 — Thu, 06 Oct 2022 10:26:43 +0000

Sometimes referred to as automated UI testing or visual regression testing, VRT checks software from a purely visual standpoint (taking a screenshot and comparing it against another approved screenshot). Cypress is an emerging test automation framework that enables teams to ship high-quality products faster.

Cypress utilizes a modern architectural approach and is fully equipped with built-in screenshot functionality and also video recording capabilities, making it one of the best test automation frameworks for Cypress visual regression testing.

For those Automation Engineers validating a UI or performing an HTML canvas test, the UI look and feel of the application is vital for our end-users. Companies spend a lot on strategies to acquire more customers through advertisements, campaigns, and more. A missing visual error in production can jeopardize their reputation. My recommendation is to start learning some Visual Testing tools.

Visual Testing is about which parts of your UI are most important to test (Visual Coverage). Perhaps visual or HTML canvas test is similar to functional testing in that it’s designed to be an automated process that runs alongside code reviews. However, unlike functional testing, the HTML canvas test results cannot be considered as Passed or Failed.

Starting your journey with Cypress UI Automated Testing? Check out how you can test your Cypress automation test scripts on LambdaTest’s online cloud.

Now execute test scripts faster than any other automation testing grid on LambdaTest’s Automated UI testing cloud.

Let’s deep dive into performing visual regression testing with the Cypress test automation framework.

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

Understanding Visual Regression Testing

Before talking about visual regression testing, we need to understand the current state of visual testing. Functional test scripts can validate the size, position, and color scheme of visual elements.

As Automation Engineers, we perform ad hoc and exploratory testing to catch edge cases and visual bugs regarding manual checkpoints. But, to be honest, it could be challenging from a manual standpoint to verify an entire screen or different screens and detect those visual diffs.

Some years ago, there was a good approach called pixel matching. It was related to a bitmap of a screen capturing various points, and its pixels were compared to a baseline bitmap. Pixel matching tools can spot pixel differences quickly and consistently and highlight the visual differences based on pixels.

If we had a great approach, what went wrong? Well, various things were wrong with snapshot or screenshot testing; we can enumerate some of the challenges using this approach:

Variation of screen resolutions
Image hardware rendering bitmaps differently
Variations in browser font size and other elements
Flakiness on dynamic content (Capturing screenshots by the element, we can skip flaky visual tests)

With this Screenshot Testing Tutorial, you will learn how to perform Automated Screenshot Testing on the LambdaTest platform.

Actual tools currently combine computer vision as the core of visual comparison and visual diffs when discussing visual regression testing. Unlike pixel matching (snapshot testing), VRT tools do not need unique environments that remain static to ensure accuracy. By blending test automation and image processing, visual regression testing checks that our application looks as it should. With functional checks alone, multiple of the challenges of frontend testing persists.

Cypress Visual Regression Testing

In this cypress tutorial for cross browser testing with Cypress, we discussed the difference between snapshot testing and visual regression testing; typically, we can find some plugins in Cypress to compare images and follow the same process of performing snapshot testing; for example, we can use the cypress-plugin-snapshots.

This open-source plugin compares the baseline and the side of the current image by the side within the Cypress Test Runner if the pixel difference is above the threshold.

Try this online Selenium Automation Grid to run your browser automation testing scripts. Our cloud infrastructure has 3000+ desktop & mobile environments. Try for free!

Cypress Version 9.0.0

Before talking about Cypress plugins, we should consider the new Cypress 9.0.0, as I updated to that version; if you want to update, please consider the following changes below; my recommendation is to check the Release notes before updating any project to the latest version.

The nodeVersion configuration option now defaults to the system. The behavior of the system option has always changed to use the Node.js binary/version that launched Cypress. If Cypress was not launched via the terminal, Cypress would use the bundled Node.js version. It could change the code behavior within your plugins file since it may be run in your system Node.js version #18684.
Windows 32-bit is not supported in Cypress #17962.
cy.contains() no longer yields the
element when it matches the content of or <style> tags <a href="https://github.com/cypress-io/cypress/issues/14861">#14861</a>.</p></li> <li><p>Attempting to add an existing built-in Cypress command using Cypress.Commands.add() will now throw an error, indicating that Cypress.Commands.overwrite() should be used instead to overwrite the behavior of existing commands <a href="https://github.com/cypress-io/cypress/issues/18572">#18572</a>.</p></li> <li><p>Custom command implementations are now typed based on the declared custom chainable <a href="https://github.com/cypress-io/cypress/issues/17496">#17496</a>.</p></li> <li><p>The bundled Node.js version was upgraded from 14.17.0 to 16.5.0. This could change the code behavior within the plugins file when using the bundled Node.js version of Cypress <a href="https://github.com/cypress-io/cypress/pull/18317">#18317</a>.</p></li> <li><p>When null is passed as the encoding to cy.readFile() or cy.fixture(), the file is treated as binary and read as a Buffer. Similarly, null passed as the encoding to cy.writeFile() allows direct writing of buffers. If the encoding is unspecified, the default remains utf8, matching the current behavior <a href="https://github.com/cypress-io/cypress/issues/18534">#18534</a>.</p></li> <li><p>Sticky elements within a fixed container will now be adequately scrolled to during action commands <a href="https://github.com/cypress-io/cypress/issues/4233">#4233</a>.</p></li> <li><p>document.referrer will now correctly reflect the correct value from the application under test after cy.visit() <a href="https://github.com/cypress-io/cypress/issues/4295">#4295</a>.</p></li> </ul> <p>If you are new to the world of Cypress or don’t know <a href="https://www.lambdatest.com/blog/cypress-test-automation-framework/?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">what is Cypress</a> in detail, you can go through this complete <a href="https://www.youtube.com/playlist?list=PLZMWkkQEwOPnxrxi544nL1vdC1noooXPx?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">Cypress Tutorial for Beginners</a>, which will walk you through the basics of what is Cypress, including the Cypress Installation & Project Setup, and help you create your first test script using Cypress.</p> <p> </p> <p>However, you can visit the <a href="https://www.youtube.com/c/LambdaTest?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">LambdaTest YouTube channel</a> for more videos on <a href="https://www.lambdatest.com/blog/cypress-test-automation-framework/?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">Cypress Testing</a>, <a href="https://www.lambdatest.com/selenium-automation?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">Selenium testing</a>, etc., so there’s never a shortage of learning opportunities.</p> <h2> <a name="cypress-visual-regression-plugin" href="#cypress-visual-regression-plugin" class="anchor"> </a> Cypress Visual Regression Plugin </h2> <p>I recommend one plugin (<a href="https://github.com/mjhea0/cypress-visual-regression?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">cypress-visual-regression</a>) for Cypress visual regression testing, which is really easy to install within Cypress.</p> <h3> <a name="setting-up-our-cypress-project" href="#setting-up-our-cypress-project" class="anchor"> </a> Setting up our Cypress Project </h3> <p><strong>Step 1</strong>: Installation</p> <div class="highlight"><pre class="highlight plaintext"><code>$ npm install cypress-visual-regression </code></pre></div> <p>We should add the following to your cypress.json file:</p> <div class="highlight"><pre class="highlight plaintext"><code>const getCompareSnapshotsPlugin = require('cypress-visual-regression/dist/plugin'); module.exports = (on, config) =&gt; { getCompareSnapshotsPlugin(on, config); }; </code></pre></div> <p>And add the command to cypress/support/commands.js:</p> <div class="highlight"><pre class="highlight plaintext"><code>const compareSnapshotCommand = require('cypress-visual-regression/dist/command'); compareSnapshotCommand(); </code></pre></div> <p><strong>Note</strong>: Please ensure import commands.js in cypress/support/index.js</p> <p>Once the configuration is ready, we can add our visual testing checkpoints into our existing cypress tests, let’s see an example:</p> <div class="highlight"><pre class="highlight plaintext"><code>describe('Visual Testing Regression', () =&gt; { it('verify UI across the pages', () =&gt;{ cy.visit(`${config.URL2}`) cy.compareSnapshot('Home Page', { capture: 'fullPage', errorThreshold: 0.0 }); }) }) </code></pre></div> <p>The code above will visit a web page, take a <a href="https://www.lambdatest.com/full-page-screen-capture?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">full page screenshot</a>, and validate zero difference between the base and the actual image comparison. You will wonder about the image baseline, as we don’t have anything in our code. To run basic comparisons, we need to have a baseline image; let’s explore that.</p> <p>Let’s run the following command:</p> <div class="highlight"><pre class="highlight plaintext"><code>npx cypress run --env type=base </code></pre></div> <p>Once the command is completed, we should see a new couple of folders like the following:</p> <p><img src="https://cdn-images-1.medium.com/max/2000/0*Ug6ZgEOMtnHC4zNB.png"/></p> <p>Once the baseline is created, we’re ready to compare and run a test; first, we need to run the following command:</p> <div class="highlight"><pre class="highlight plaintext"><code>npx cypress run --env type=actual </code></pre></div> <p>After the command runs successfully, we will see the folder structure like the following.</p> <p><img src="https://cdn-images-1.medium.com/max/2000/0*YJZ0DWrhaDw05FEW.png"/></p> <p>As we can see from the image above, we have three folders created, one for the actual result, one for the base image, and another for spotting the difference between the images. So basically, we are done with our basic configuration; next time we run, we can spot any discrepancies in our command line.</p> <p><img src="https://cdn-images-1.medium.com/max/2912/0*-jOy4Ay7RrRCLG_b.png"/></p> <h3> <a name="implementing-cypress-plugin-snapshots" href="#implementing-cypress-plugin-snapshots" class="anchor"> </a> Implementing Cypress Plugin Snapshots </h3> <p>There is another exciting plugin for snapshot tests in Cypress. Same API as Jest that we can use with the Cypress GUI. To install the plugin, we need to run:</p> <div class="highlight"><pre class="highlight plaintext"><code>npm i cypress cypress-plugin-snapshots </code></pre></div> <p>If you are using Cypress 9.0.0, which in my case, then you need to add an extra parameter like this:</p> <div class="highlight"><pre class="highlight plaintext"><code>npm i cypress --legacy-peer-deps cypress-plugin-snapshots </code></pre></div> <p>Just avoid version conflicts and, in many cases, break the installation process. The –legacy-peer-deps flag was introduced with v7 to bypass peerDependency auto-installation; it tells NPM to ignore peer deps and proceed with the installation anyway. It is how things used to be with NPM v4 thru v6.</p> <p>As we did for the previous plugin, we need to do the same for cypress-plugin-snapshot; add this to your cypress.json configuration file:</p> <div class="highlight"><pre class="highlight plaintext"><code>"ignoreTestFiles": [ "**/__snapshots__/*", "**/__image_snapshots__/*" ], "env": { "cypress-plugin-snapshots": { "imageConfig": { "threshold": 0.01 } } } </code></pre></div> <p>Then add to your cypress/plugins/index.js file and change it to look like this:</p> <div class="highlight"><pre class="highlight plaintext"><code>const { initPlugin } = require('cypress-plugin-snapshots/plugin'); module.exports = (on, config) =&gt; { initPlugin(on, config); return config; }; </code></pre></div> <p>Similar to your cypress/support/index.js file and add the following line:</p> <div class="highlight"><pre class="highlight plaintext"><code>import 'cypress-plugin-snapshots/commands'; </code></pre></div> <p>After installation is done, we are ready to create some tests; my suggestion is to create a new test spec under your integration folder ‘cypress/integration/.’</p> <div class="highlight"><pre class="highlight plaintext"><code>import config from './config.json' import MainPage from '../../page-objects/components/MainPage' describe('Visual Testing Cypress Snapshots', () =&gt; { before(function(){ cy.visit(`${config.URL1}`) }) it('verify full Page is displayed correctly', () =&gt;{ cy.document().toMatchImageSnapshot() }) it('verify Multiple elements across the pages', () =&gt;{ //First element Screenshot MainPage.elementOne() //Second Element Screenshot MainPage.elementTwo() }) it('Verify blogs related to Cypress', () =&gt; { MainPage.search('Cypress') //Full page plus renaming screenshot cy.document().toMatchImageSnapshot({ name: 'screenshot with Blogs related to Cypress' }) }) }) </code></pre></div> <p><strong>Code Walkthrough</strong></p> <p><strong>Step 1</strong>: We first import config.json since it contains the test links located in /cypress/integration/e2e_tests/config.json</p> <div class="highlight"><pre class="highlight plaintext"><code>import config from './config.json' </code></pre></div> <p><strong>Step 2</strong>: We need to import our MainPage component; we use another component to reuse our HTML elements.</p> <div class="highlight"><pre class="highlight plaintext"><code>import MainPage from '../../page-objects/components/MainPage' </code></pre></div> <p><strong>Step 3</strong>: We visit the URL. The base URL is stored in Cypress.json to ensure better portability and maintainability; also, we use the Before Fixture.</p> <div class="highlight"><pre class="highlight plaintext"><code>cy.visit(`${config.URL1}`) </code></pre></div> <p><strong>Step 4</strong>: In our first test, we take a full-page screenshot to validate that our web page is displayed correctly and there are no UI errors.</p> <div class="highlight"><pre class="highlight plaintext"><code>cy.document().toMatchImageSnapshot() </code></pre></div> <p><img src="https://cdn-images-1.medium.com/max/3200/1*K7Xz_iT3enrJDNOIihhCkA.png"/></p> <p><strong>Step 5</strong>: In our second test, we want to validate multiple elements to make sure they are displayed correctly; this is useful in case of any specific element like a banner or footer on our webpage. For this case, we have our elements inside of our MainPage component located in cypress/page-objects/components/Mainpage.js</p> <div class="highlight"><pre class="highlight plaintext"><code>//First element Screenshot MainPage.elementOne() //Second Element Screenshot MainPage.elementTwo() </code></pre></div> <p><img src="https://cdn-images-1.medium.com/max/3032/1*VRTTUCD6C1w9gr9S1l68cQ.png"/></p> <p><img src="https://cdn-images-1.medium.com/max/3200/1*zUfJyLVEwDIzjsGtNwMX6g.png"/></p> <p>If we want to avoid flakiness related to dynamic content or other factors, it is better to capture elements to compare discrepancies; we want to ignore full-page screenshots and focus on our web pages’ specific UI instability areas.</p> <p><strong>Step 6</strong>: For the last test, we want to validate specific search results; in this case, we are searching in our blog for Cypress-related material and taking a full-page screenshot. Last but not least, we are renaming the screenshot to customize our image comparison.</p> <div class="highlight"><pre class="highlight plaintext"><code>MainPage.search('Cypress') //Full page plus renaming screenshot cy.document().toMatchImageSnapshot({ name: 'screenshot with Blogs related to Cypress' }) </code></pre></div> <p>A critical aspect of this plugin is the screenshot location, and the plugin saves the actual image in cypress/integration/<strong>image_snapshots</strong>. The snapshot compares against another picture of the current interface on subsequent runs, and if the tool finds any difference, the test fails. But what if we want to change our current image baseline? Well, in that case, as there is no way to run a baseline command, the easiest way to do that is to remove the previous images saved on cypress/integration/<strong>image_snapshots</strong> and rerun our tests to get a new baseline.</p> <p><img src="https://cdn-images-1.medium.com/max/2000/0*rMnscJF8oo-qfg5K.png"/></p> <p>Open Cypress test runner and click on the corresponding test to execute the same.</p> <p><img src="https://cdn-images-1.medium.com/max/3200/0*6bGlenAGKy_mIP4W.png"/></p> <p>And here is the test execution, which indicates that we have a new baseline:</p> <p><img src="https://cdn-images-1.medium.com/max/3200/0*65RRx-CSSE9-b7qM.png"/></p> <p>One more time to see that the image is correct:</p> <p><img src="https://cdn-images-1.medium.com/max/3200/0*Z_PcrHj-Nay8pMTH.png"/></p> <p>You can download the code from the GitHub repository.</p> <p>Take this certification to showcase your expertise with end-to-end Cypress testing and stay one step ahead.</p> <p>Here’s a short glimpse of the Cypress 101 certification from LambdaTest:</p> <p> </p> <p><strong><em>Check our <a href="https://www.lambdatest.com/selenium-automation?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=webpage">selenium automation testing</a> cloud infrastructure has 3000+ desktop & mobile environments. Try for free!</em></strong></p> <h2> <a name="how-to-use-visual-regression-plugin-on-cypress-cloud-grid" href="#how-to-use-visual-regression-plugin-on-cypress-cloud-grid" class="anchor"> </a> How to use Visual Regression Plugin on Cypress Cloud Grid </h2> <p>We can use a <a href="https://www.lambdatest.com/?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">Cloud Cypress Grid</a> like LambdaTest, which provides automated <a href="https://www.lambdatest.com/?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">cross browser testing</a> on 40+ browsers and operating systems, and <a href="https://www.lambdatest.com/blog/what-is-parallel-testing-and-why-to-adopt-it/?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">Parallel testing</a> to expedite the test execution in a scalable way. In addition, it will help improve our overall visual test coverage by resulting in better visual standpoint product quality as we can cover different combinations using the same test scripts.</p> <p>Starting your journey with <a href="https://www.lambdatest.com/cypress-parallel-testing?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">Cypress Parallel Testing?</a> Check out how you can test your Cypress test scripts on LambdaTest’s online cloud.</p> <p>Now execute test scripts faster than any other automation testing grid on <a href="https://www.lambdatest.com/automated-ui-testing?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">LambdaTest’s Automated UI testing cloud</a>.</p> <p>To get started, you have to install <a href="https://accounts.lambdatest.com/detail/profile?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">LambdaTest Cypress CLI</a> on your machine. Trigger the following command to install the same:</p> <div class="highlight"><pre class="highlight plaintext"><code>npm install -g lambdatest-cypress-cli </code></pre></div> <p>After installation is completed, set up the configuration using the below command:</p> <div class="highlight"><pre class="highlight plaintext"><code>lambdatest-cypress init </code></pre></div> <p>Once the command is completed, lambdatest-config.json is created in the project folder. Next, enter the LambdaTest credentials from the <a href="https://www.lambdatest.com/support/docs/testing-locally-hosted-pages/?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">LambdaTest Profile Section</a>.</p> <div class="highlight"><pre class="highlight plaintext"><code>"lambdatest_auth": { "username": "", "access_key": "" </code></pre></div> <p>Here is how you can configure the required browser & OS combinations in lambdatest-config.json:</p> <div class="highlight"><pre class="highlight plaintext"><code>{ "lambdatest_auth": { "username": "", "access_key": "" }, "browsers": [ { "browser": "MicrosoftEdge", "platform": "Windows 10", "versions": [ "latest" ] }, { "browser": "Chrome", "platform": "Windows 10", "versions": [ "latest" ] }, { "browser": "Firefox", "platform": "macOS Big Sur", "versions": [ "latest" ] }, { "browser": "Firefox", "platform": "Windows 10", "versions": [ "latest" ] } ], </code></pre></div> <p>The run_settings section in the JSON file contains the desired Cypress test suite capabilities, including Cypress_version, build_name, visual feedback settings, number of parallel sessions, etc.</p> <div class="highlight"><pre class="highlight plaintext"><code>"run_settings": { "Cypress_config_file": "Cypress.json", "build_name": "build-visual-testing", "parallels": 5, "specs": "./Cypress/integration/e2e_tests/*.spec.js", "ignore_files": "", "feature_file_suppport": false }, </code></pre></div> <p>Tunnel_settings in the JSON file lets you connect your local system with LambdaTest servers via an SSH-based integration tunnel. Once this tunnel is established, you can <a href="https://www.lambdatest.com/support/docs/testing-locally-hosted-pages/?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">test locally hosted pages</a> on all the browsers currently supported by Cypress on LambdaTest.</p> <div class="highlight"><pre class="highlight plaintext"><code>"tunnel_settings": { "tunnel": false, "tunnelName": null } </code></pre></div> <p>Now that the setup is ready, it’s time to run the tests; remember that our run_settings file displays the parallels field as five once we trigger our execution in parallel without any extra parameter.</p> <div class="highlight"><pre class="highlight plaintext"><code>lambdatest-cypress run </code></pre></div> <p>Shown below is the test execution status from the <a href="https://automation.lambdatest.com/?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">LambdaTest Automation Dashboard</a>.</p> <p><img src="https://cdn-images-1.medium.com/max/3200/0*p7qxAVlwUAh02oE5.png"/></p> <p>Here is the execution snapshot, which indicates the progress of test execution:</p> <p><img src="https://cdn-images-1.medium.com/max/3200/0*TGTSabTsn-hRkaLj.png"/></p> <p>To summarize, the significant benefit of Cypress visual regression testing on the cloud is achieving optimal visual test coverage without modifying the core logic of the test code to incorporate multiple OS and Browsers.</p> <p><img src="https://cdn-images-1.medium.com/max/3200/0*Gcd6Rby2vyofT4mT.png"/></p> <p>To view test performance metrics, navigate to the <a href="https://analytics.lambdatest.com/test-overview?utm_source=devto&utm_medium=organic&utm_campaign=oct06_kj&utm_term=kj&utm_content=blog">LambdaTest Analytics Dashboard</a>. The Test Overview will provide a snapshot of tests consistent with stable behavior. Meanwhile, the Test Summary will display the total number of tests passed or failed, as well as any completed tests and pending tests.</p> <p><img src="https://cdn-images-1.medium.com/max/3200/0*E7Wwm1ZFcKOlXWtj.png"/></p> <p>With this Visual Testing Tutorial, you will learn how to perform Smart Visual UI Testing on the LambdaTest platform.</p> <p> </p> <h2> <a name="final-thoughts" href="#final-thoughts" class="anchor"> </a> Final Thoughts </h2> <p>Visual testing does the heavy lifting to contribute to our UI validation; no matter if you use open source tools or paid tools, visual inconsistencies deeply influence the user journey, which means they need to be eliminated. Performing Cypress visual regression testing can help us validate quickly, correctly, and comprehensively, making it indispensable for any enterprise looking to have an online presence.</p> <p><img src="https://cdn-images-1.medium.com/max/2000/0*cEkQvmcpDYfmkWML.png"/></p> <p>“Just because your test automation is working doesn’t mean that it adds value.” — Enrique A Decoss</p> <p>Remember, we need to change our test automation landscape positively. If you are not including visual testing in your automation test scripts, this is an excellent opportunity to make your test scripts more robust; at the end of the day, automation testing must add value to our customers.</p> <p>Happy Visual Testing!</p>

How To Find Broken Links Using Cypress [With Examples]

enriquee20 — Tue, 04 Oct 2022 11:24:46 +0000

Have you ever experienced a 404 error? From an end user’s perspective, a 404 error (or broken link) experience can be a complete turn-off. Apart from annoying end-user experience, broken links (or dead links) on a website can dampen the SEO (Search Engine Optimization) activity.

The more 404 pages you have on your site, the less time users spend on the site. To reduce the bounce rate and build a top-notch online reputation for your website, it is essential to check for broken links using Cypress. It is relatively easy to check broken links on the website by performing Cypress testing compared to other test automation frameworks like Selenium.

In this blog of the Cypress tutorial series, we deep dive into the ‘why’ and ‘how’ of finding broken links on a website. We also demonstrate how to find broken links using Cypress (a test automation framework best suited for modern web applications).

Why Find Broken Links On A Website

Search engine algorithms pay special attention to how users behave on your website. As a result, their online behavior has a significant role in the ranking process. HTTP 404 code is one of the most frustrating things your visitors can come across, and the chances are that they might never revisit your website. It is like handing over your customer base to your competition.

Apart from a negative user experience, high bounce rates due to broken links can negatively affect your SEO. So although Google’s algorithm may not directly consider bounce rate, it can indeed hurt your online rankings.
This is where a broken link checker using Cypress framework can be handy, as it can be regularly triggered to ensure that the website is free from broken links.

In this Appium automation tutorial, learn about Appium and its benefits for mobile automation testing.

Major Reasons For Broken Links

You can find broken links on a website only when you have clarity about the various conditions that might result in broken links. There are umpteen reasons that result in 404 errors (or broken links/dead links); the major ones are mentioned below:

The page has been removed from the website
The page is moved to another URL, and the redirection is done incorrectly
You entered the wrong URL address
Server malfunctions (though it is a rarity)
You have entered an expired domain address

Broken links are often left for long periods after the page has been deleted or moved. This is because websites that link to this page are not informed that the site doesn’t exist anymore or can be found under a new URL. In addition, broken HTML tags, JavaScript errors, and broken embedded elements can also lead to broken (or dead) links on a website.

Irrespective of the criticality of the ‘page’ from the larger scheme of things (of your website), it is essential to keep a regular check for broken links on the website. Though you can find broken links using Selenium, finding broken links on a website using Cypress is recommended due to the simplicity involved in the implementation process.

Essential HTTP Status Codes To Detect Broken Links

Whenever a user visits a website, the server responds to the request sent by the browser with a three-digit response code. This code is called ‘HTTP Response Status Code,’ which indicates the status of the HTTP request.

Here are the five major classes of HTTP status codes:

Informational responses (100–199)
Successful responses (200–299)
Redirects (300–399
Client errors (400–499)
Server errors (500–599)

Though it is important to have a top-level understanding of all the HTTP status codes, our interest mainly lies in HTTP 404 status, which indicates whether a particular link on the website is broken. A 404 error means that although the server is reachable, the specific page you are looking for is not present (or available) on the server. Essentially, it’s a page that doesn’t exist, or it’s broken. The 404 error code can appear in any browser, regardless if you’re using Google Chrome or Firefox.

Here are some of the many ways in which 404 errors are shown to the end user:

404 Not Found Error
404 HTTP 404
404 Page Not Found
Error 404 Not Found
HTTP 404 Not Found
The requested URL was not found on this server
404 File or Directory Not Found

If you want a quick walk-through of the Cypress framework, check out our blog that explains the architecture of Cypress automation framework. Alternatively, you can also check out LambdaTest YouTube Channel, where we have a video that explains how you can get started with Cypress.

Starting your journey with Cypress End-to-End Testing? Check out how you can test your Cypress test scripts on LambdaTest’s online cloud.

How To Find Broken Links Using Cypress

Till now, you would have understood the importance of checking broken links on your website? So, with the platform all set, let’s look at how to find broken links using Cypress. For starters, Cypress is a next-generation front-end testing tool built for the modern web; Cypress testing enables you to write faster, easier, and more reliable tests.

In case you are coming from a Selenium automation background, make sure to check out the differences between Selenium and Cypress from our blog that covers Cypress vs Selenium comparison. Saying that, let’s focus on our problem about broken links and how to build some tests to validate that using Cypress test automation.

Let’s take a sample HTML page that contains four relative hyperlinks:

<a href="/at-home-coronavirus-testing">Testing</a>
    <a href="/paying-for-covid-19-testing/">Paying for covid Testing</a>
    <a href="/covid-19-antibody-testing">Covid19 antibody Testing</a>
    <a href="/covid-19-testing-statistics">Testing Statistics</a>

As you can see, we have four links, and we need to click on each link, check the redirect URL, and then go back to our main page. So, how do you find broken links using Cypress considering the above HTML page.

What if we come up with an implementation that is limited to finding which out of the four are broken in nature. If the implementation is hardcoded for four links, it will lead to scalability issues, especially if the checker is used on a different web page.

Here is the sample code that uses the Cypress framework to find broken links on the website. As mentioned earlier, this is not a scalable approach and should be avoided when finding broken links on large-scale websites.

describe('Test Navigation', () => {
  it('can navigate and test the pages', () => {
    cy.visit('[https://www.testing.com/at-home-coronavirus-testing/'](https://www.testing.com/at-home-coronavirus-testing/'));

    cy.get('main:contains("Testing")');
    cy.go('back');

   cy.visit('[https://www.testing.com/paying-for-covid-19-testing/'](https://www.testing.com/paying-for-covid-19-testing/'));
   cy.get('main:contains("Test")');
   cy.go('back');

   cy.visit('[https://www.testing.com/covid-19-antibody-testing/'](https://www.testing.com/covid-19-antibody-testing/'));
   cy.get('main:contains("Testing")');
   cy.go('back');


   cy.visit('[https://www.testing.com/covid-19-testing-statistics/'](https://www.testing.com/covid-19-testing-statistics/'));
   cy.get('main:contains("Testing")');
   cy.go('back');

  });
});

In our example below, we are clicking on every page and checking the specific assertion, it does not follow the design patterns, and we can improve the way we get the links on our website.

Let’s take a look at the following example.

it('Navigate through the links using loops', () => {

  const pages = ['Testing Covid', 'Paying for Covid19 Test', 'Test Antibody Covid19', 'Testing Statistics']

  cy.visit('/')

  pages.forEach(page => {

    cy.contains(page).click()
    cy.location('pathname').should('eq', `/${page}`)
    cy.go('back')

  })

})

As you can deduce from the code above, we are looping against the specific pages and validating the page information. We created a ‘forEach’ loop that will iterate through the array where the entire procedure is repeated. Particularly useful if, for any reason, our navigation bar changes items. We’ll add an item to the array, and our test works.

“If you are using Cypress to find broken links on your website, it is essential to note that Cypress changes its host URL to match the URL of your AUT (Application Under Test). The basic requirement from Cypress is that the URLs being navigated should have the same superdomain for the entirety of a single test.”

Navigating to subdomains works fine, but Cypress will throw an error if you visit two different superdomains. Thus, you can see different superdomains in other tests but not in the same test.

Instead of opening every link on the test website, we can simply check links with the href attribute and check their HTTP status code. If the return code is 404, it means that that particular link is a broken (or dead) link.

Test your native, hybrid, and webapps across all legacy and latest mobile operating systems on most powerful Andoird emulator online.

Demonstration: Finding Broken Links With Cypress

In order to demonstrate how to find broken links on your website using Cypress, let’s perform a broken links test on the LambdaTest Blog. There are close to 500+ posts on the LambdaTest blog, and our broken link checker using Cypress will check every link (i.e., under href attribute).

Here is the test scenario used for finding broken links on a website using Cypress:

Test Scenario

Go to LambdaTest Blog on Chrome.
Collect all the links present on the page.
Send HTTP requests for each link.
Print whether the link is broken or not on the terminal.

Project Structure

It is time to create our test under the integration folder; as you can see below, we have a test called test-example.js. Shown below is the directory structure:

Implementation

For ensuring that the code is extensible and maintainable to check for broken links on the ’N’ number of websites, we keep the test URL in a separate JSON file (e.g., config.json).

{
    "URL1": "https://www.lambdatest.com/blog",
    "URL2": "https://www.lambdatest-playground.com"
}

As seen above, we have two test URLs (i.e., URL1 and URL2); however, we would run the test only on URL1. Shown below is the implementation (that uses JavaScript).

import config from './config.json'

describe('Test Broken Links', () => {

    it('verify navigation accross the pages', () =>{

        cy.visit(`${config.URL1}`)
        cy.on('window:confirm', cy.stub().as('confirm'))
        Cypress.on('uncaught:exception', (err, runnable) => {
            // returning false here prevents Cypress from
            // failing the test
        return false
        })

        cy.wrap('passed').as('ctrl')
        cy.get("a:not([href*='mailto:]']").each($el => {

                if ($el.prop('href').length > 0) {
                    const message = $el.text()
                    expect($el, message).to.have.attr("href").not.contain("undefined")
                    cy.log($el.attr('href'))                       
                }
        })
    })
})

Code Walkthrough

Step 1:

We first import config.json since it contains the test links.

import config from './config.json'

Step 2:

We now visit a remote URL. The base URL is stored in Cypress.json to ensure better portability and maintainability.

cy.visit(`${config.URL1}`)

Step 3:

We need to ignore some uncaught exceptions when we are testing some websites. In this case, we can use the following code to turn off uncaught exception handling for specific errors. Cy.on is to catch a single exception or event; in this case, we have used this code to fail a test on purpose, using a small hack.

cy.on('window:confirm', cy.stub().as('confirm'))
        Cypress.on('uncaught:exception', (err, runnable) => {
            // returning false here prevents Cypress from
            // failing the test
        return false
   })

Step 4:

cy.wrap is used for logging purposes in Cypress. In this case, we are using it as a control variable to test or fail the test depending on our parameters.

cy.wrap('passed').as('ctrl')

Step 5:

We use “each” to get the elements, excluding “mailto:” and empty ones. With this, we will get the URLs that we want to monitor for broken links with Cypress.

cy.get("a:not([href*='mailto:]']").each($el => {

Step 6:

We are validating head links, and one of those always presents anchors for the code block shown below. As a part of the process, we validate them all. We combine the selectors wherever possible.

if ($el.prop('href').length > 0) {
      const message = $el.text()
      expect($el, message).to.have.attr("href").not.contain("undefined")
      cy.log($el.attr('href'))                       
}

Execution

Now, let’s add to Cypress and run it from there; if you already have an npm project, please open a terminal using VS Code and run the following command:

npm install cypress

Now that Cypress is installed, let’s run the following command to get the Cypress folder:

npx Cypress open

For configuring Cypress, we open Cypress Test Runner, which creates Cypress.json. This JSON file is used to store any configuration values you supply.

{
    "watchForFilesChanges": false,
    "chromeWebSecurity": false,
    "viewportWidth": 1000,
    "viewportHeight": 600,
    "waitForAnimation": true,
    "defaultCommandTimeout": 6000,
    "execTimeout": 60000,
    "pageLoadTimeout": 60000,
    "requestTimeout": 150000,
    "responseTimeout": 150000,
    "video": true,
    "failOnStatusCode": false
}

Open Cypress test runner and click on the corresponding test to execute the same.

Here is the test execution, which indicates that there are zero broken links on the test website:

Take this certification to showcase your expertise with end-to-end testing using Cypress automation framework and stay one step ahead.

Here’s a short glimpse of the Cypress 101 certification from LambdaTest:

Perform Cypress Parallel Testing on LambdaTest and speed up the testing and release process. Check out how you can test your Cypress test scripts on LambdaTest’s online cloud.

How to find broken links using Cypress on Cloud Grid

Cypress testing on cloud grid like LambdaTest helps in running tests on a wide range of browser and OS combinations. Parallel execution helps in accelerated test execution as well as achieving optimal browser coverage.

Cypress on LambdaTest helps you run Cypress tests at scale. You can check out our earlier blog that deep dives into the essentials on how to perform Cypress testing at scale with LambdaTest.

To get started, you have to install LambdaTest Cypress CLI on your machine. Trigger the following command to install the same:

npm install -g lambdatest-cypress-cli

After installation is completed, setup the configuration using the below command:

lambdatest-cypress init

Once the command is completed, lambdatest-config.json is created in the project folder. Next, enter the LambdaTest credentials from the LambdaTest profile section.

"lambdatest_auth": {
      "username": "<Your LambdaTest username>",
      "access_key": "<Your LambdaTest access key>"

Here is how you can configure the required browser & OS combinations in lambdatest-config.json:

"browsers": [
      {
         "browser": "Chrome",
         "platform": "Windows 10",
         "versions": [
            "latest-2"
         ]
      },
      {
         "browser": "Firefox",
         "platform": "Windows 10",
         "versions": [
            "latest"
         ]
      },
      {
         "browser": "MicrosoftEdge",
         "platform": "Windows 10",
         "versions": [
            "latest"
         ]
      }
   ],

run_settings section in the JSON file contains the desired Cypress test suite capabilities, including Cypress_version, build_name, visual feedback settings, number of parallel sessions, etc.

"run_settings": {
      "Cypress_config_file": "Cypress.json",
      "build_name": "build-broken-links",
      "parallels": 1,
      "specs": "./Cypress/integration/e2e_tests/*.spec.js",
      "ignore_files": "",
      "feature_file_suppport": false
   },

Tunnel_settings in the JSON file lets you connect your local system with LambdaTest servers via an SSH-based integration tunnel. Once this tunnel is established, you can test your locally hosted pages on all the browsers currently supported by Cypress on LambdaTest.

"tunnel_settings": {
    "tunnel": false,
    "tunnelName": null
}

Now that the setup is ready, it’s time to run the tests by triggering the following command:

lambdatest-cypress run

Shown below is the test execution status from the Automation Dashboard:

After the test execution, click on the test name to view the automation logs for debugging the respective test.

You can view the live video feed, screenshots for each test run, view console logs, terminal logs, and do much more using Cypress on LambdaTest.

One crucial aspect of running the tests using LambdaTest and Cypress is parallel testing. This can be achieved using two methods. The first option is passing the parallelization level from the command line:

lambdatest-cypress run --parallels 5

The other option is to set the parallelization level using the parallels key in lambdatest-config.json.

{
  "run_settings": {
    ...
    "parallels": 5,
    ...
  }
}

Here is the execution snapshot, which indicates the progress of test execution:

Here’s quick video if you have doubts regarding how to handle iframes in Cypress.

To summarize, the major benefit of Cypress testing on the cloud is achieving optimal test coverage without making modifications to the core logic of the test code.

Test your emulator online mobile websites and smartphone apps using our scalable on-cloud mobile emulator. LambdaTest is preferred by 600k+ developers across the globe to fulfill their mobile testing needs.

It’s A Wrap

It’s inevitable 404 errors will appear on your site. Broken links can also impact the rankings on search engines; make sure you proactively monitor the links of your website. Finding broken links on your website or an HTTP 404 is as vital as posting unique and high-quality content.

Check your 404s as a part of continuous testing, and you can include Cypress tests as part of your testing tools. Putting time aside to update your website and perform technical testing will help you stay ahead of the competition.

We know that we must enable, nurture, and foster an ecosystem that includes high-quality success. Every line of test code is an investment in our codebase. Tests will be able to run and work independently always. Lastly, in this Cypress tutorial, we saw how LambdaTest and Cypress integration ensure seamless user experience across different browsers on 40+ browser versions simultaneously.

Happy Bug Hunting with Cypress!!