DEV Community: Sonikasinghh

Cypress Best Practices For Test Automation

Sonikasinghh — Tue, 22 Nov 2022 09:27:02 +0000

Cypress is an amazing framework for testing your frontend applications. However, there are mistakes that you can make which can cause you to slow down your development and testing processes. You could face challenges that are difficult to surpass, like handling authentication and dealing with web servers, or even worse, dealing with third-party authentication providers, etc.

In this blog on Cypress best practices, I will show you the best practices of Cypress automation and the common mistakes people make when writing the test code while performing Cypress E2E testing. I will also show you how to avoid these mistakes to make your development process faster, free from bugs, and constant code refactoring.

Here are the key learning points from the blog:

How to model your tests based on a real application?
How do you write effective tests in isolation?
Freeing yourself from page objects
Choosing an effective testing strategy for logging in to your application
How to leverage direct access to its state?

Cypress is amazing overall, but if you don’t do it the right way and don’t follow the Cypress best practices, the performance of your tests will decrease drastically, you will introduce unnecessary errors, and your test code will be unreliable and flaky.

For example, your code may work today and break tomorrow after a third-party provider adds some changes to their website.

This blog will teach you the Cypress best practices to never make such mistakes and write reliable, high-quality test codes while performing Cypress testing.

What is Cypress?

Cypress is also widely used for E2E (end to end) testing, so you don’t have to separate your tests and write your front-end, back-end, and database tests separately. Instead, you can replicate real user scenarios and use Cypress for end-to-end testing.

According to the State of JS 2021 survey, Cypress is the third most popular testing framework, showing that many developers and QA engineers are switching to the Cypress test automation framework.

Though Cypress is a relatively new kid on the block; it has quickly established its position as the test automation framework of choice for JavaScript applications, as evident from the number of Forks (2.4K) and Stars (38.9K) on GitHub for the project. Cypress’ popularity can be attributed to some handy features such as a runtime inspector, time travel debugging, an ability to run tests in parallel, and plugins.

The ever-increasing downloads for Cypress speak a lot about the popularity of this open-source test automation framework.

Moreover, the Cypress Community is a thriving environment that features plenty of learning opportunities. It is well-moderated and provides you with access to top minds in software testing and web development. Apart from the active Cypress community, there are Cypress Ambassadors that you can use to learn from. Cypress Ambassadors are experienced developers and engineers that have created amazing applications using Cypress.

As compared to other testing frameworks like Selenium, Cypress is picking up pace. If you are coming from a Selenium background and intrigued to know more about the Cypress automation tool, you can check out the Selenium vs Cypress comparison.

Cypress best practices for testing

One thing that is fondly mentioned in automation testing is “No amount of bad code can be fixed with automation.” What this essentially means is that the maximum ROI from test automation can be attained if we follow the best practices of the framework that is being used to write automation tests.

As per my experience with Cypress UI testing, here are some of the Cypres best practices to avoid Anti-patterns in Cypress that should be leveraged to come up with top-notch automation tests:

Login programmatically

Anti-Pattern: Using the UI to log in
Best Practice: Programmatically log into the application and widely use the application’s state

For example:

describe("Testing protected routes", () => {
 beforeEach(() => {
   cy.visit("/login")
   cy.get('[data-cy="email"]').type("jon@example.com")
   cy.get('[data-cy="password"]').type("password")
   cy.get('[data-cy="submit"]').click()
 })
})

This gets your job done. But the problem with this is that this uses your application UI for authentication, and after the authentication is done, it redirects to the page that you want.
This also means the login page must work before any other specific page you want to test. This style of writing tests is not in isolation, which is not among Cypess best practices.

Let’s say you want to test the settings page. To do that, you log in and introduce the login page, which means you have failed the test in isolation. This will also be extremely time-consuming and counterproductive if you have hundreds of pages. If the process of logging in and redirecting to the desired page takes 1.0 seconds, it will increase the testing time by 100 seconds if you have a hundred pages.

The better approach for this is to log in programmatically. What does that mean?

Let’s first see how authentication happens when someone logs in. Most of the time, the user sends an email and password through a POST request to the backend server, and the server will send back the user data and a token to the client.

The client saves that token in the browser’s local storage and sends it in the authorization header whenever another request is sent to the backend. This way, the backend can identify which user has sent the request.

To sign in programmatically, we need to use another Cypress command called Cypress request cy.request(). The method makes HTTP requests outside the constraints of the browser. It’s not bound by CORS or any other security restrictions.

Let me touch base on what is CORS? CORS stands for Cross-Origin Resource Sharing. It is an HTTP header-based mechanism that helps servers indicate the origins in which the browsers send the request. Most servers only allow requests from specific trusted origins.

Coming back to cy.request(), the awesome thing about cy.request() is that it uses the browser’s user agent and cookie store, so it behaves exactly as the request did come from the browser, but it is not bound by the restrictions.

In a nutshell, the difference between cy.request() and cy.visit() is that cy.visit() redirects and uses the browser to visit the indicated URL, which means when you visit a URL with cy.visit() it will open up in the browser and downloads all the assets of the page and runs all the JavaScript code.

On the other hand, cy.request() only sends HTTP requests to a URL; you can not see it visually, and it does not download any website assets or run any JavaScript code.

What we can do now is send a POST request to our backend server with the email and password in the request body using cy.request(), and after we get back the response, we will save the token in our browser’s local storage.

describe("Testing protected routes", () => {
  beforeEach(() => {
    cy.request("http://localhost:3000/api/auth/login", {
      email: "jon@example.com",
      password: "password",
    }).then((r) => {
      window.localStorage.setItem("token", r.body.token)
    })
  })
})

This sends a request every time a particular page is being tested.

One of Cypress best practices is to build a custom command for our login code.

Cypress.Commands.add("login", (email, password) => {
  cy.request("http://localhost:3000/api/auth/login", {
    email,
    password,
  }).then((r) => {
    window.localStorage.setItem("token", r.body.token)
  })
})

And re-use our custom command in our test codes.

describe("Testing protected routes", () => {
  beforeEach(() => {
    cy.login("jon@example.com", "password")
  })
})

Now, this is a much better practice and much faster than logging in using the UI. It saves you a lot of time; it’s more maintainable and reliable since we are not relying on selectors that could change during development.

Watch this video to learn how Cypress can be used to automate accessibility testing.

Choosing best-suited locators

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!

Choosing best-suited locators

One of the most common mistakes in writing tests is using selectors that are too brittle and subject to change. These include selectors coupled with CSS styling and JavaScript event listeners.

For example, let’s use LambdaTest’s eCommerce Playground to run a test using brittle selectors (not recommended)

describe("Testing home page", () => {
  it("should go to product page", () => {
    cy.visit("<https://ecommerce-playground.lambdatest.io/>")
    cy.get("#mz-product-listing-image-97213254-0-1").click()
  })
})

In this example, we want to click the first element of the “Deals of the day” slider, the problem with the code above is that it is using the element id to click it.

This will work (for now), but more products will be added to the slider in the future. It is not a guarantee that this product will be there, so Cypress can not find an element with the given id, and the test will fail. To learn more about finding elements in Cypress, you can read this blog on finding HTML elements using Cypress locators.

You can use Cypress best practices, something like data-cy="first-slider-item" as the element attribute and use cy.get('[data-cy="first-slider-item"]') in Cypress to get access to the element.

Now it is a guarantee that the code will always run no matter if the id changes or the styling of the element changes.

You should refactor your code to this:

describe("Testing home page", () => {
  it("should go to product page", () => {
    cy.visit("https://ecommerce-playground.lambdatest.io/")

    cy.get('[data-cy="first-slider-item"]').click()
  })
})

The problem with using too generic selectors is that it might work at first as you don’t have a very complicated UI, but you could easily break your selectors as you expand and add more features in the application.

This way you might introduce broken selectors and unnecessary failed tests that should actually be considered as passed tests.

For example, let’s say you want to select an element **button **and click it. Here are some ways that you could do it and why you should use them or not:

cy.get(‘button’).click(): This is too generic, there might be more than one button in the page or you might add more buttons in the future.
cy.get(‘.btn.btn-primary’).click(): This one is also subject to change. You might want to change the classes to update the styling of the button in the future.
cy.get(‘#main’).click(): Better but not the best since it is linked to CSS Styling and JavaScript event listeners.
cy.get(‘[name=submission]’).click(): Coupled to the name attribute, which has HTML semantics.
cy.contains(‘Submit’).click(): This is much better, but this is coupled with the HTML elements content. It depends if you really want the button to contain “Submit”. If you want the test to fail if it doesn’t contain “Submit”, then you should use it.
cy.get(‘[data-cy=submit]’).click(): Best practice, not subjected to any change in any way possible.

Recommended	Not recommended
✅ data-cy	❌ class
✅ data-test	❌ id
✅ data-testid	❌ name

Using data-cy, data-test or data-testid makes it clear to everyone that this element is used directly by the test code.

Code example:

// cypress/support/commands.ts
Cypress.Commands.add("getBySelector", (selector, ...args) => {
 return cy.get(`[data-test=${selector}]`, ...args)
})
Cypress.Commands.add("getBySelectorLike", (selector, ...args) => {
 return cy.get(`[data-test*=${selector}]`, ...args)
})

getBySelector yields elements with a data-test attribute that match a specified selector.
getBySelectorLike yields elements with a data-test attribute that contains a specified selector.

Writing the types for TypeScript:

declare global {
  namespace Cypress {
    interface Chainable {
      getBySel: (
        selector: string,
        ...args: Partial<Loggable & Timeoutable & Withinable & Shadow>[]
      ) => Chainable<any>

      getBySelLike: (
        selector: string,
        ...args: Partial<Loggable & Timeoutable & Withinable & Shadow>[]
      ) => Chainable<any>
    }
  }
}

Assigning Return Values

Anti-Pattern: Assigning return values of Cypress commands
Best Practice: Using closures and aliases

Cypress does not run synchronously, which means that you can not ever assign the return value of any Cypress command.

Do not assign or work with return values of any Cypress command; commands are enqueued and run asynchronously. There is no guarantee that the behavior of the tests will be the same if they are dependent on the return values.

This is a common mistake that people mostly make:

// this won't work 
// do not write your code like this
const button = cy.get('button')
const form = cy.get('form')
button.click()

Since commands are enqueued and run asynchronously, this code does not work. Do not ever assign any value to Cypress commands.

But don’t worry…

Don’t panic yet, Cypress has provided us with a few other techniques that we can use to get the values of any selected element.

How to access the return values of any Cypress command?

There are some ways that you could access the return values of any Cypress command:

Using Closures
Using Variables
Using Aliases

Closures

If you’ve worked with JavaScript enough, you definitely are quite familiar with JavaScript promises and how to work with them.

You can access the value that each Cypress command yields using the .then() command.

Example:

Let’s use this simple form demo to run a simple test using closures. Basically, we want to grab a text from a random element from the DOM and type that element in an input which will also display the text in a different div element.

This is just a simple example of using closures in our code.

it("should be equal", () => {
  cy.visit("https://www.lambdatest.com/selenium-playground/simple-form-demo")

  cy.get("h2").then(($h2) => {
    const text = $h2.text() // gets the text in the p tag

    cy.get("input").first().type(text)

    // click the button that will show the input
    cy.get("#showInput").click()

    // get the div which contains the message
    // using another closure to get the text
    cy.get("#message").then((message) => {
      expect(message.text()).to.equal(text)
    })
  })
})

As you can see we are using .then() after we are getting the element h2 we also use .text() which can only be accessed on the returned element, which is $h2 in this case. This will return the text value that is inside the first h2 element of the DOM.

After we get the text of the first h2 element, we want to type that text inside the first input element and click the button to show it on the other div. We also assert that the text in the message should be equal to the text in the first h2.

As you can see, both texts are equal, that’s why our test passes.

Variables
You will not be using variables in most of your code or you will be hardly using them, but variables also have their own use cases and are sometimes important to use.

If your application’s state changes throughout running the test codes, then you might want to use variables to compare your previous state value to the next state value.

Example:

Let’s write a simple HTML code that contains a span that holds a state value of a counter and a button that increments the counter.

<button>increment</button>
counter = <span id="num">0</span>
<script>
 var counter = 0
 document.getElementById("num").innerHTML = counter
 document
   .getElementsByTagName("button")[0]
   .addEventListener("click", function () {
     counter++
     document.getElementById("num").innerHTML = counter
   })
</script>

We want to compare the previous state and the next state with Cypress and make an assertion to make sure the value is incremented each time the button is clicked.

cy.get("#num").then(($span) => {
 // the current number
 const num1 = parseInt($span.text())
 cy.get("button")
   .click()
   .then(() => {
     // the number after the state updates
     const num2 = parseInt($span.text())
     expect(num2).to.eq(num1 + 1)
 })
})

As you can see we first get the value in the span with .text() and click the button to increment it, finally compare the new value to be equal with the old value +1.

Aliases

Sometimes you want to re-use the return values of the Cypress commands that you run inside the hooks like before and beforeEach.

Using .then() certainly won’t help with that.

beforeEach(() => {
  cy.get("button").then(($btn) => {
    const text = $btn.text()
  })
})

it("does not have access to text", () => {
  // how do we get access to text ?
  // .then() is not useful in this scenario.
})

You can share the context of any value that you want by using the .as() command.

The .as() commands lets you assign an alias for later use; it yields the same subject it was given from the previous command.

You can then access that alias with this.alias or cy.get(‘@alias’) with a @ in the beginning.

beforeEach(() => {
 // alias the $btn.text() as 'text'
 cy.get("button").invoke("text").as("text")
})

it("has access to text", function () {
 expect(this.text).to.equal("Click me")
})

Having test isolation

Anti-Pattern: Having tests rely on each-other
Best Practice: Tests should always be able to be run independently from any other test

Let’s say you want to test if a particular input exists, fill in the text input, and then submit the form.

This includes three tests. Here is how most people do it, which is NOT the Cypress best practices and you should avoid doing this:

describe("Texts should be equal", () => {
 it("should visit lambdatest form demo", () => {
cy.visit("https://www.lambdatest.com/selenium-playground/simple-form-demo")
 })
 it("should find the input", () => {
   cy.get("#user-message").should("exist")
 })
 it("should type in the input", () => {
   cy.get("#user-message").type("Hello World")
 })
 it("should click the button", () => {
   cy.get("#showInput").click()
 })

 it("should show the message", () => {
   cy.get("#message").should("contain", "Hello World")
 })
})

What is wrong with this code? Why is this a bad idea?

This approach to testing your code is depending on the previous state of the application, for example, the step of .should("contain", "Hello World") depends on the previous step of clicking the button and this also depends on the previous state of typing in the input.

These steps obviously depend on each other and fail completely in isolation, which is essential in writing your tests.

Instead, you should combine all of these steps into one test.

Here is the recommended way to do it:

describe("Texts should be equal", () => {
  it("should fill in the form and show the message", () => {
    cy.visit("https://www.lambdatest.com/selenium-playground/simple-form-demo")

    cy.get("#user-message").should("exist")

    cy.get("#user-message").type("Hello World")

    cy.get("#showInput").click()

    cy.get("#message").should("contain", "Hello World")
  })
})

If you think you need to run some other tests differently, it’s a good idea to share some of the code by using beforeEach.

The **beforeEach **hook runs the code inside of it before running any tests.

describe("Testing login page ...", () => {
  beforeEach(() => {
    cy.visit("/login")
  })
  it("test 1", () => {
    // ...
  })

  it("test 2", () => {
    // ...
  })
})

For example in this code, Cypress will visit the login page before running any of the codes inside the it blocks.

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

Creating small tests with a single assertion

Anti-Pattern: Creating different tests with a single assertion for the same element
Best Practice: Adding multiple assertions in the same test

Cypress is different and not the same as running unit tests, it runs a series of asynchronous lifecycle events that reset the state between tests.

This means writing single assertions in one test will make your tests run very slowly and cause really bad performance.

Adding multiple assertions is much faster than creating different tests; therefore, don’t be afraid to add multiple assertions in one test.

What if you want to know which tests have failed? Don’t you need to write different titles for each test? The answer is NO. Since you will be able to see “visually” which tests have failed, you don’t need to write every single assertion in a different test, you can easily create multiple assertions in one test.

As per Cypress, they consider 30+ commands in Cypress tests to be pretty common and normal.

This is a simple example of the correct usage of writing multiple assertions.

describe("Testing login page", () => {
  it("should type and validate inputs", () => {
    cy.visit(
   "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
    )

    cy.get("#input-email")
      .type("jon@doe.com")
      .should("have.value", "jon@doe.com")
      .and("include.value", "@")
      .and("not.have.value", "jon@doe")
  })
})

Unnecessary Waits

Anti-Pattern: Waiting for an arbitrary time period
Best Practice: Not using cy.wait() for a large portion of your tests

In Cypress, you almost never need to use cy.wait() an arbitrary number for anything. Cypress users seem to do this very often, but fortunately, there are better ways to do this.

You should never use cy.wait() with any of the following commands:

cy.request()
cy.visit()
cy.get()

The command cy.request() will not resolve until it receives the response from the server, so adding an arbitrary waiting time is not necessary at all.

This is a great feature of Cypress and one of the Cypress best practices. If you set an arbitrary number of 2 seconds for a request and the request takes 0.1 seconds, you will slow down the testing process by 20 times.

Also, if you wait for 1 second and the request takes 2 seconds now, you get an error because the request is not resolved yet. So Cypress made this pretty easy, and you can use cy.request() without worrying about waiting for it to resolve.

The same is true for cy.visit(). It will only resolve when every single asset has been loaded, including JS and CSS files.

Web Servers

Anti-Pattern: Starting a web server using Cypress commands cy.exec() and cy.task()
Best Practice: Start a web server before running Cypress

Every time you run cy.exec() and cy.task(), the process must eventually exit. If not, Cypress will not continue any other commands.

If you start a server with Cypress, you will introduce many problems because:

You have to background the process
No access via terminal
No valid access to logs
Every time your tests run, you’d have to work out the complexity around starting an already running web server
Port conflicts

Using the after() hook could solve your problem and shut down the server, but the after() hook only runs after the test is completed. Also, it is not guaranteed that the after() hook will run every single time!

Since you can always restart/refresh in Cypress, then the code in the after hook will not always run.

What should you do instead?

You should instead start your server before running the Cypress tests and shut it down whenever it ends.

We recommend using the wait-on module

npm start & wait-on http://localhost:8080

Then run your tests:

Using a global baseUrl

Anti-Pattern: Using cy.visit() without a baseUrl
Best Practice: Set a baseUrl in your cypress.json

Setting up a global baseUrl saves you from hard-coding the URL every time you use one of the Cypress commands cy.request() and cy.visit().

Also, if you do not set up a global baseUrl, Cypress will automatically go to **https://localhost** + a random port, which will show an error. By having a baseUrl configured, you save yourself from seeing this error when cypress first opens up.

If you haven’t configured a baseUrl in your cypress.json, here is how you should re-write your code:

let’s say you have visited the login page:

cy.visit("http://localhost:3000/login")
Change it to:
cy.visit("/login")
cypress.json
{
 ...
 "baseUrl": "http://localhost:3000"
 ...
}

Visiting external websites

Anti-Pattern: Visiting 3rd party websites
Best Practice: Only testing what you control and using cy.request() with 3rd party APIs

You should always avoid using cy.visit() to visit any external website and avoid interacting with the UI at all costs.

Why shouldn’t you ever use cy.visit() and the UI to interact with third-party websites and servers?

It takes a lot of time and slows you down.
The website might change without you knowing about it.
Their website could be having issues.
They might want to block you because of automation.
They might be running A/B campaigns.

Testing logging in with OAuth

Instead of using cy.visit here are some ways you can handle logging in to third-party providers:

Use stub

Using after or afterEach hooks

Anti-Pattern: Using after or afterEach hooks to clean up the state
Best Practice: Cleaning up the state before running the tests

We see people write their state clean-ups right after their test ends. This could cause multiple problems, including introducing unnecessary failing tests and slowing down your testing performance.

Here is an example of how most beginners tend to do it, which is not recommended:

afterEach(()=> {
  cy.cleanDb()
})

it('should add a new user', ...)
it("should some other stuff", ...)
it('should do something else', ...)

While this code seems to be fine, it is actually not, because it is not a guarantee that any code inside of the afterEach hook will run at all. This could leave you with an unwanted state in your application.

Why is afterEach not a guarantee to run?

Let’s say you refresh your browser in the middle of the test, this will restart your test instantly without running any code inside the afterEach hook, leaving you with an unwanted state.

So, the next time you start your testing process, you will encounter many errors and failed tests, because of the old state that the previous test created when you refreshed/closed the test.

Let’s look at another code example that most people tend to write, which is also not recommended

beforeEach(() => {
 cy.login()
})

afterEach(() => {
 cy.logout()
})

it('some', ...)
it('more', ...)
it('tests', ...)

This code will log in and log out the user for every test, which is sometimes unnecessary.

Cypress leaves you with the same state that the previous test leaves behind. It’s of the Cypress best practices to always take advantage of this state and write your tests based on this.

We don’t have to worry about debugging later because debugging in Cypress is unlike any other test library. It has an unmatched debuggability that helps you write your tests in this style.

What should you do instead?

Avoid using afterEach and after as much as you can. This way you can leverage the state of the previous tests and run your tests much faster and much more performant.

If you want to clean the state, do it before starting the test, meaning, put it in the beforeEach block. This way, you will always ensure you are starting your test in a clean and untouched state.

Bonus Tip: Use Cloud Cypress Grid to test at scale

Check out this e2e testing comprehensive tutorial that covers what E2E Testing is, its importance, benefits, and how to perform it with real-time examples.

Bonus Tip: Use Cloud Cypress Grid to test at scale

Cypress cloud grids like LambdaTest allow you to perform Cypress testing at scale. LambdaTest allows you to perform automated cross browser testing on an online browser farm of 40+ browsers and operating systems to expedite the test execution in a scalable way. Moreover, it increases the test coverage with better product quality.

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.

In this example, I will show you how to run parallel Cypress browsers using LambdaTest. We will use LambdaTest’s eCommerce Playground to visit the registration page and create an assertion.

// /cypress.json
{
  "baseUrl": "https://ecommerce-playground.lambdatest.io"
}

// /cypress/integration/test.spec.ts
describe("Testing register page", () => {
  it("should find a text", () => {
    cy.visit("/index.php?route=account/register")

    cy.contains("Register Account").should("exist")
  })
})

To run your Cypress test on LambdaTest, install the LambdaTest Cypress CLI using the following command:

npm install -g lambdatest-cypress-cli

Cypress test on LambdaTest ” width=”546″ height=”211″ class=”aligncenter size-full wp-image-30582″ />

Setup configurations on which you want to run your test — Once you have installed the lambdatest-cypress CLI, now you need to set up the configuration. You can do that using the following command:

lambdatest-cypress init

This will put the configurations inside lambdatest-config.json.

If you are using TypeScript, don’t forget to add typescript with the specified version in the npm dependencies.

"npm_dependencies": {
         "cypress": "9.0.0",
         "typescript": "^4.7.2" // don't forget to add this line
      }

This is an example of the LambdaTest configuration file. Don’t forget to update the Username and Access Key with valid credentials. You can find the same in the LambdaTest Profile Section once you log on to LambdaTest.

{
   "lambdatest_auth": {
      "username": "your-lambdatest-username",
      "access_key": "your-lambdatest-token"
   },
   "browsers": [
      {
         "browser": "Chrome",
         "platform": "Windows 10",
         "versions": [
            "latest-1"
         ]
      },
      {
         "browser": "Firefox",
         "platform": "Windows 10",
         "versions": [
            "latest-1"
         ]
      }
   ],
   "run_settings": {
      "cypress_config_file": "cypress.json",
      "build_name": "build-name",
      "parallels": 5,
      "specs": "./**/*.spec.ts",
      "ignore_files": "",
      "feature_file_suppport": false,
      "network": false,
      "headless": false,
      "reporter_config_file": "",
      "npm_dependencies": {
         "cypress": "9.0.0",
         "typescript": "^4.7.2"
      }
   },
   "tunnel_settings": {
      "tunnel": false,
      "tunnel_name": null
   }
}

As shown in the browsers array, we have specified two browsers with the specified operating systems.

And we have also specified the value of the parallel to be 5, which means LambdaTest will automatically run these tests in different browsers with a maximum of 5 parallel tests.

Now it’s time to run the Cypress UI automation test in LambdaTest. Use the following command for that:

lambdatest-cypress run

This will automatically upload your tests to the secure LambdaTest Cypress Grid and help you perform Cypress parallel testing.

Visit the Automation Dashboard to view the status of the tests.

You will be able to see your tests there and see the logs and videos recorded during the tests.

You can further deepen your knowledge with this webinar on Cypress, which will help you perform scalable and reliable cross browser testing with Cypress.

If you are a developer or a tester and want to take your Cypress expertise to the next level, you can take this Cypress 101 certification and stay one step ahead.

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

Conclusion

Cypress is a great testing framework if appropriately used, followed by the best practices.

Following some of the Cypress best practices could be irritating or somewhat difficult to implement. But they will definitely pay off in the long run and save you a lot of time while performing Cypress E2E testing. If not, you will introduce errors and failed tests and slow down the process.

Following these Cypress best practices will make your tests much more performant, giving you a seamless testing experience without introducing errors or failures in the future.

Do check out the detailed Cypress tutorial if you want to explore the immense number of features Cypress offers.

Podman vs Docker: All You Need To Know!

Sonikasinghh — Mon, 21 Nov 2022 05:33:35 +0000

Docker and Podman are great container management engines and serve the same purpose in building, running, and managing containers.

Docker has been in the containerization market for quite a while. It has proved its worth and increased its job market demand. It was first developed by Docker Inc. in 2013 and has been used by some of the biggest names in technology, such as Google and Facebook, thus making it the most popular container engine out there.

Now that containers have become a lot more popular and are being used almost everywhere, other tools like Podman show up to make this even better and solve some specific problems we face with containerization.

In this Podman vs Docker comparison blog, you will learn about both Podman and Docker.
Moreover, you will get a much better understanding of both container engines. At the end of the blog post, you will be able to decide which container engine suits you the best.

Chances are you are using Docker currently, so I will also explain how to migrate from Docker to Podman without having any issues in the later section of this blog on Podman vs Docker.

So, let’s get started.

What is Containerization?

Containerization is a very efficient method of virtualization that is available out there. It makes it much easier for developers to test, build and deploy large-scale applications.

Containers and Virtual machines are similar, but they’re not the same. Since they are so similar, some people tend to confuse them because they do the same thing but differently.

Why Podman vs Docker?

If we look at Google trends, we see that the search interest for Podman is on the rise and all-time increasing. We will likely see Podman become more popular in the next few years.

Docker is still a leading player in the field, and I don’t think it is going anywhere anytime soon, but the charts tell us that the overall interest in Docker is decreasing.

Either developer are losing interest in Docker, or they have migrated to another software that could do their jobs better than Docker.

Before getting into the Podman vs Docker differences, let’s start by understanding what a container is. Some people tend to confuse the two because they both do the same thing (virtualization), but they’re quite different.

Containers vs Virtual Machines

In Virtual Machines (VMs), the system’s resources are distributed between multiple virtual machines. The VMs run separately and can have different operating systems in them.

Containers, on the other hand, only virtualize software layers above the operating system level, which means you can have multiple virtualized environments with only one operating system. To learn more about the differences, you can read through this blog, which discusses Containers vs Virtual Machines.

Containerization is the packaging of software code with just the OS libraries and dependencies required to run the code to create a single lightweight executable, called a container.

A comprehensive User Acceptance Testing (UAT) tutorial that covers what User Acceptance Testing is, its importance, benefits, and how to perform it with real-time examples.

Why are containers important?

Containers play a considerable role in deploying applications, especially microservices. Microservices are a few little services that communicate, send, and receive data from and to each other.

As per the report, Netflix uses over 1,000 microservices now. Each deployed application controls a specific aspect of the colossal Netflix operation. For example, a microservice is only responsible for determining your subscription status to provide content relevant to that subscription tier.

Microservices allow teams to work on different parts of their applications separately without interfering with another team’s work. They are flexible, maintainable, and easily adaptable.

The microservices design patterns have helped developers to develop, scale, and maintain their projects efficiently. However, when it comes to deployment, they might face a few challenges, especially in large-scale applications.

If you don’t use containers, you will have to write a bunch of instructions to your DevOps team to run the code on their side. This increases the number of errors that could occur in the application.

To learn more about microservices, you can refer to this blog on how to test a microservice architecture application.

Challenges of not using Containers

If the DevOps team makes a mistake in following your instructions, they will not be able to run the code on their side. So they will get back to you, and you’ll have to find that little mistake.

For example: let’s say you are using MongoDB version 4.0, but for production, there was a mistake, and version 4.1 has been installed. One of your microservices is not compatible with that specific version.

These errors are often introduced in large-scale applications and can be challenging to debug.

As your application grows, it requires more dependencies and microservices, which will be quite a headache to re-deploy manually every time something new is added.

Containerization makes this so much easier. You don’t have to give instructions to your DevOps team as the instructions are written in a Dockerfile. The container engine will automatically download and install every dependency that your code requires to run.

FROM node:16

# Create app directory
WORKDIR /usr/src/app

# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm@5+)
COPY package*.json ./

RUN npm install
# If you are building your code for production
# RUN npm ci --only=production

# Bundle app source
COPY . .

EXPOSE 8080
CMD [ "node", "server.js" ]

Docker will read the file and instructions and download the dependencies for that specific application, ending with a specific command to run the application. In this case, we are pulling a specific version of the official NodeJs Docker image.

These image repositories could depend on other repositories and dependencies, and they also can rely on other dependencies on and on. Docker will handle all that hard work in the background when it builds and runs containers.

Since containers use only high-level software, it makes them lightweight and can be created, modified, and deleted with ease.

Most container runtime systems also have a robust ecosystem. Many public repositories of container images are ready to be downloaded and executed.

For example, you can download the latest version of Selenium from DockerHub and run it inside a Docker container with just one single command.

docker pull selenium/standalone-docker

docker run selenium/standalone-docker

This will download the official Selenium Docker image from DockerHub and all of the required dependencies for it. Then Selenium will run inside of the Docker container.

Today, almost every large company uses containerization to test, build, and deploy its applications. Containers have proved their importance over the last few years, especially Docker.

What is Docker?

Docker is a Platform as a Service (PAAS) product that uses operating-system-level virtualization in small, lightweight packages called containers.

For starters, PaaS is a complete development and cloud-hosted platform in the cloud. It allows businesses and developers to host, build, and deploy applications.

Docker is also open-source and helps developers to build, deploy, run and manage containerized applications. It uses a REST API running in the background to listen to requests and perform operations accordingly. This process is called the Docker daemon (or dockerd).

Docker daemon is a background process responsible for managing all containers on a single host. It can handle all Docker images, containers, networks, storage, etc.

Docker uses the containerd Daemon that listens to REST API requests to manage most of the work that Docker does. For example, managing images, managing containers, volumes, and networks. Containerd listens on a Unix socket and exposes gRPC endpoints. It handles all the low-level container management tasks, storage, image distribution, network attachment, etc.

How does Docker work?

The containerd daemon will pull the container images from the container registries. Then it turns over the process of creating the container to a low-level runtime named runc.

runc is a CLI tool for running containers on Linux according to the OCI specification.

OCI is a collaborative project hosted under the Linux Foundation and designed to establish standards for containers. Container engines like Docker, CRI-O, and containerd rely on the OCI compliant to interface with the operating system and create the running containers.

It is designed to be used by higher-level container software. Hence, the process of running a container goes from running it through the Docker daemon, containerd, and then run.

Docker Image

A Docker image is like a template that acts as a set of instructions to build a Docker container. A Docker image contains application code, libraries, tools, dependencies, and other files needed to run the application.

Docker Volume

Let’s say you have a Docker container with a MongoDB database inside it. Usually, this container saves every bit of data inside the container itself.

The problem with this is that if you want to delete the container for whatever reason, you will lose all of the data that you have accumulated.

With Docker volumes, you can save the necessary information that you need in the host machine. They are preferred where you want the data to persist in docker containers and services.

Docker Network

A Docker network helps attach containers that can communicate with each other. Hence, Docker is not just the software to build and run containers. It is also a cloud platform to upload and download your container images to the cloud.

With Docker, you can create, build, and run containers compatible with any operating system. In other words, if you have Docker on your system and your code runs on your machine, it is guaranteed that this code will run on another device if they have Docker installed.

A quick summary about Docker:

Docker uses a daemon which is a background process listening to API requests to manage the containers accordingly
Docker lets you build and run super lightweight containers
Docker is a PAAS based on multiple software, including a cloud-hosted registry to share and download Docker images called DockerHub.

What is Podman?

Podman is a similar container engine to Docker. It is also used for developing, managing, and running OCI containers. Podman can manage the entire container ecosystem like pods, containers, images, and container volumes using a library libpod.

What are pods?

One of the key features of Podman is that it allows you to create pods. A pod is an organizational unit for containers. Pods are an essential part of the Kubernetes container orchestration framework.

You can use Podman to create manifest files that describe pods in a declarative format. Kubernetes can consume these manifest files written in YAML.

Unlike Docker, containers in Podman can be run as root or non-root users. We will discuss this Podman vs Docker difference in more detail in the later section of this blog on Podman vs Docker.

Podman does not rely on a daemon to develop, manage or run containers. Since Podman does not have a daemon to manage containers, Podman uses another service manager to manage all of the services and support running containers in the background called Systemd.

Systemd creates control units for existing containers or generates new ones, with Systemd vendors can install, run, and manage their container applications since most are now exclusively packaged and delivered this way.

Podman, with the help of Buildah, can build images without using a daemon. Buildah is a tool for building OCI-compatible images through a lower-level core utils interface.

Just like Docker has a CLI since images created by Docker and Podman are compatible with the OCI standard. Podman can push and pull from container registries such as the Docker Hub and Quay.io.

If you are already familiar with Docker, you can easily migrate from Docker to Podman (more on this later). You can also alias Podman to docker without having any problems alias docker=podman. This means you can use the same commands with Podman as with Docker.

Podman, just like Docker, relies on an OCI-compliant like RunC to interface with the operating system and create the running containers. Hence it will make Podman very similar to other container engines like Docker.

Podman also uses REST API that Podman provides to manage containers; this REST API is only available on Linux. To interact with this REST API, Podman has a client which is available on all of the major operating systems Windows, macOS, and Linux.

If the Podman REST API is only available on Linux, how can we use it in Windows or macOS?

Even though containers are Linux, Podman also runs on Mac and Windows. It provides a native Podman CLI and embeds a guest Linux system to launch the containers.

This guest is also called a Podman machine and can be managed by using the podman machine command.

A quick summary about Podman:

Podman helps you find containers on DockerHub or quay.io or an internal registry server.
Easily runs containers from pre-built container images.
Builds new layers or containers with a few tweaks.
You can easily share your container images anywhere you want with just one command podman push.

Running a Redis server inside a container using Podman

Running containers with Podman is pretty easy and similar to Docker. To do that, run the following command:

podman run redis

Podman will run a Redis server based on the official Redis image inside of a container. The container will be run in detached mode declared by -d and will be named Redis as specified with —-name.

The container will expose the ports and attach it to the same port on the host machine, which is the default Redis port as specified with -p 6379:6379.

After you run the command, Podman will check if the Redis image already exists in the local machine. If it does, it will build a container based on that image. If it doesn’t, it will look for that image from DockerHub and download the latest version.

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

Podman vs Docker Comparison

Generally, Podman and Docker do the same thing. However, there are some differences between the two container engines, Podman vs Docker.

Here are the main differences between Podman vs Docker:

Architecture: Podman has a Daemonless architecture

Docker daemon is a background process responsible for managing all containers on a single host. It can handle all Docker images, containers, networks, storage, etc. Docker daemon uses a REST API to listen to requests and perform operations accordingly.

So, Docker needs this daemon to run in the background to manage, create, run, and build containers. Docker has a client-server logic mediated by the Docker daemon.

Podman, on the other hand, does not need a daemon. It has a (daemonless architecture), which helps users to start running containers (rootless). In other words, Podman does not require root privileges to manage containers.

Root privileges

Since Docker needs a daemon to manage its containers, it will need root permission to run the processes.

As Podman does not have a daemon, it has a (daemonless architecture). It does not require root privileges for its containers.

Rootless Execution

At first, when Docker came out, you could not run Docker without root permission. However, the rootless mode was introduced in Docker at v19.03 and graduated from experimental in Docker Engine v20.10.

However, Docker rootless doesn’t come out right out of the box. Some configurations and third-party packages should first be installed on the host before installing Docker.

So, yes, you can run Docker and Podman as root. But it is good to know that Podman introduced running containers on rootless, which also comes with a few limitations.

Limitations of Docker rootless

Rootless mode on Docker is not perfect, and some issues come with running containers with Docker rootless:

Not being able to run containers on privileged ports, which are all of the ports below 1024. Otherwise, they will fail to run.
Only the following storage drivers are supported:
overlay2 (only if running with kernel 5.11 or later or Ubuntu-flavored kernel).
fuse-overlayfs (only if running with kernel 4.18 or later, and fuse-overlayfs is installed).
btrfs (only if running with kernel 4.18 or later, or ~/.local/share/docker is mounted with user_subvol_rm_allowed mount option).
Vfs.
Cgroup is supported only when running with cgroup v2 and systemd.
The following features are not supported:
AppArmor
Checkpoint
Overlay network
Exposing SCTP ports
To use the ping command.
IPAddress shown in docker inspect and is namespaced inside RootlessKit’s network namespace. This means the IP address is not reachable from the host without nsenter -ing into the network namespace.
Host network ( docker run --net=host ) is also namespaced inside RootlessKit.
NFS mounts as the docker “data-root” is not supported. This limitation is not specific to rootless mode.

Security

Does Podman have higher security than Docker? Earlier, we looked at how Podman can run rootless because it has a (daemonless architecture), and Docker can not run rootless because it requires a daemon to run and manage the containers while comparing Podman vs Docker.

But why is this important? Why not having a daemon and being able to run containers without root privileges is essential? The answer is that we do not give root privileges to applications that we don’t trust, and we do trust our containers and applications.

But that’s not the case. Let’s say an attacker has found a way to access one of your containers! Since Docker can only run with root privileges, any malicious actor (i.e., attacker) can take wrong actions on your server with those root privileges.

With Podman, if an attacker gets access to your container, they will be able to do you harm, but they still won’t be able to do actions that require root privileges. Therefore Podman is considered safer than Docker.

Building images

Docker is a self-sufficient platform. It can build images and run containers on its own without the need for any other third-party tool.

Podman, on the other hand, is only designed to run containers and not build them. That’s where Buildah comes in. Buildah is an open-source tool that makes building Open Container Initiative (OCI) container images.

Podman, with the help of Buildah, can build its OCI container images.

Docker Swarm and docker-compose

Docker Swarm is a container orchestration platform used to manage Docker containers. With the Docker Swarm, you can run a cluster of Docker nodes and deploy scalable applications without other dependencies required.

Docker Swarm can also manage multiple containers across multiple hosts and connect them all. Docker Swarm obviously can be used with Docker right out of the box without any problem.

Podman does not support Docker Swarm, but other tools can be used with Podman, such as Nomad, which comes with a Podman driver.

Docker-compose is a tool to manage applications with multiple containers. The main difference between Docker compose, and Docker swarm is that docker-compose runs only on a single host while Docker swarm connects various hosts.

Docker automatically is compatible with docker-compose and can work well with it right out of the box.

In the previous versions of Podman, Podman did not have a way to simulate the Docker daemon necessary for Docker compose to work, so that’s why Podman compose was used.

Now, in version 3.0, Podman introduced the podman.socket, a UNIX socket that replaces the Docker Daemon.

All in one vs modular

Podman has a modular approach, relying on specialized tools for specific tasks, while Docker is a monolithic independent tool. Docker is a monolithic, powerful independent tool. By monolithic, it means that Docker does not rely on any other third-party tool to manage containers, run, build or handle any other task related to the containers.

This one is a significant difference between Podman vs Docker technologies.

As we discussed, Podman relies on many additional third-party tools to achieve the same goals as Dockers. For example, it uses Buildah to build container images, while Docker does not need Buildah or any other third-party tool to build images.

Here’s the summary of the Podman vs Docker comparison.

DOCKER	PODMAN
Uses a Daemon.	Has a daemon-less architecture.
It can only run with root privileges.	Able to run root-less.
Less secure since all containers have root privileges.	More secure since containers don’t have root privileges.
Docker is a self-sufficient tool and builds images on its own.	Podman can not build images by itself. It uses another tool called buildah to build images.
It supports the Docker swarm, and Docker compose right out of the box.	It does not support the Docker swarm or Docker compose.
Docker is a monolithic independent tool.	Podman relies on other third-party tools.

Since we have learned about Podman vs. Docker comparison, is it safe to consider Podman a replacement for Docker? Let’s check this in the next section of this Podman vs Docker blog.

Is Podman a replacement for Docker, or can they work together?

Some developers use Podman for production and Docker for development. Since they’re both OCI compliant, compatibility won’t be a problem. However, it’s better to compare Podman vs Docker before moving ahead.

You can use Docker for development to make your work easier and use Podman for production to benefit from the added security it provides and make your application more efficient.

Podman can be a primary containerization technology option if you start a project from scratch. If the project is ongoing and already using Docker, it depends on the specifics, but it might not be worth the effort. As a Linux native application, it demands Linux skills from the developers involved.

How to migrate from Docker to Podman?

Migrating from Docker to Podman could be quite easy and simple to implement. The same commands you use to use Docker can also be used for Podman, so you don’t have to worry about memorizing new commands, which makes migrating really easy.

Some developers just alias Docker to Podman, and everything works quite the same, but the processes are handled by Podman instead of Docker.

Running a Node.js container with Podman

First, you must have Podman installed on your computer. If you want to follow along with this short tutorial, you can download the sample node.js application from this GitHub repository.

Since both Podman and Docker comply with the OCI container standard, Podman can also build containers from a Dockerfile, so if you can build and run a container from a **Dockerfile **with Docker, then you can run it with Podman as well.

Let’s build the container on this Dockerfile:

FROM node:16

# Create app directory
WORKDIR /usr/src/app

# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm@5+)
COPY package*.json ./

RUN npm install
# If you are building your code for production
# RUN npm ci --only=production

# Bundle app source
COPY . .

EXPOSE 3000
CMD [ "node", "server.js" ]

To build the container, run the following command:

      podman build -t my-node-app .

After you run the command, Podman will execute the Dockerfile and build the image in your local machine.

You can show the container images available on your local device by running podman images.

We only created one image called my-node-app, but if you notice, we have another additional image since the container that we are trying to run relies on node:16. Podman will automatically download that image to run the container that we want to run.

After you have built the image, you can then run an instance of this by running a container using the following command:

podman run --name my-node-js-container -p 3000:3000 localhost/my-node-app

The --name tag will specify the name of the container, -p will map the port inside of the container to the port on the host machine -p host:container.

Finally, add the localhost/my-node-app at the end to specify the container image we want our new container to run on.

Congratulations, your server is now running on port 3000 inside a container run by Podman. You can access it from your browser.

All the commands we used in this tutorial were the same as Docker commands. That’s why migrating from docker to Podman is easy, and developers get used to it effortlessly.

Another cool feature about Podman is that you can stop or remove all containers using the —-all flag. With Docker, you could not have used that.

For example, if you want to stop all containers with Podman, you can run podman stop —-all. If you’re going to do the same thing with Docker, you have to run docker stop $(docker ps -a -q), which is a bit difficult to memorize.

Integrating Docker or Podman with Selenium Grid is easy and helps you perform Selenium automation testing. However, the capabilities offered by the Selenium Grid with Docker or Podman can be further enhanced by integrating an online Selenium Grid like LambdaTest.

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

LambdaTest is a cross browser testing platform that allows you to perform manual and automated browser testing of websites and web apps on an online browser farm of 3000+ browsers and operating systems combinations.

LambdaTest’s reliable, scalable, secure, and high-performing test execution cloud empowers development and testing teams to expedite their release cycles. It lets you run parallel tests and cut down test execution by more than 10x.

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

Conclusion

In this Podman vs Docker blog, we have seen that both Docker and Podman are amazing in running and managing containers. You can build and deploy large-scale applications with both of them.

If you are more concerned about security in your applications or planning to use Kubernetes to orchestrate your containers, Podman is the better choice for you.

If you want a well-documented tool with a much larger user base, then Docker is the better option for you.

How To Get Started With Cypress Debugging

Sonikasinghh — Fri, 18 Nov 2022 09:41:30 +0000

One of the most important tasks of a software developer is not just writing code fast; it is the ability to find what causes errors and bugs whenever you encounter one and the ability to solve them quickly.

According to The Cost of Poor Software Quality in the US: A 2020 Report by Herb Krasner of CISQ, the cost of bugs is estimated at roughly $607 billion only for the United States.

This includes all the costs relating to unsuccessful projects and maintaining legacy systems, but it doesn’t include some other aspects like security issues, technical debt, and some other issues that add up to a huge price of $2 trillion.

Even though we are not building applications with Cypress, we’re only testing them; it is still important to keep our test suites away from bugs as much as possible.

And if we introduce bugs, we should have the ability to spot them and fix them as fast as possible.

That is why Cypress does a pretty good job of providing developers with tools and commands that make it easy to debug the test suites easily.

In this Cypress testing tutorial on Cypress debugging, I will talk about some of the best ways to debug your Cypress tests and explain each in detail. I will also point out some pitfalls you might get into and explain how Cypress actually works and why some things are not happening very intuitively.

So, let’s get started!

Using debugger in Cypress

Sometimes, when running tests, especially large and complicated ones, it could be very difficult for you to know what exactly went wrong and which part of the code failed to do as expected.

The debugger is very helpful in these kinds of situations. You can stop the test execution at any time and look up the application’s state to see if everything works as it should.

If you have been in the development field for quite a while, you might already know how to use the debugger in other parts of your applications.

However, if you are unfamiliar with Cypress debugging, using the debugger in Cypress might work differently than you think it should.

Even though using a debugger in Cypress is quite similar to using the debugger in other parts of your application (like your front end), it doesn’t work the same way.

You can only use the debugger in Cypress inside the.then() function. Otherwise, it does not work the way it is supposed to.

Let me explain…

Let’s see what goes wrong if we add the debugger outside a .then() function.

it('should work as usual', () => {
  cy.visit('https://ecommerce-playground.lambdatest.io')

  cy.get('[data-test="some-selector"]')
  debugger // Doesn't work
})

Running the test:

As you can see, the debugger will pause the test to run before the test even starts.

If you have used a debugger before, your expectation might be that first, the cy.visit() and cy.get() functions should run and complete, and then the debugger should pause the test, but that’s not the case.

So, what happened there? Why did the test pause immediately?

Based on the Cypress documentation, it is said that the commands in Cypress are all “Asynchronous,” so what does that mean?

In Cypress, when a set of commands are invoked, they get enqueued for later, and after the whole, it() block is finished, Cypress will run all of the commands in order.

it('hides the thing when it is clicked', () => {
  cy.visit('/my/resource/path') // Nothing happens yet

  cy.get('.hides-when-clicked') // Still nothing happening
    .should('be.visible') // Still absolutely nothing
    .click() // Nope, nothing
    .should('not.be.visible') // Definitely nothing happening yet
})

// Ok, the test function has finished executing...
// We've queued all of these commands and now
// Cypress will begin running them in order!

Based on this information, now you should know why the debugger pauses the test immediately instead of pausing the test after the other two commands have finished running.

The two commands that come before the debugger are only being enqueued to run later, but the debugger, which is not a Cypress command, will not be enqueued and will be invoked immediately.

Causing the test to pause immediately before the other commands can be executed in the queue.

That’s why you should always use the debugger inside the .then() function. This will ensure that the Cypress command will run and complete, and then the debugger will pause the execution of the tests.

Now, let’s re-write the test again, but this time using the debugger inside of the .then() function

it('should only pause when the cy.get() function finishes executing', () => {
  cy.visit('https://ecommerce-playground.lambdatest.io/')

  cy.get('h2')
    .should('exist')
    .then($h2 => {
      debugger
    })
})

In this section of this tutorial on Cypress debugging, the debugger will only pause the test if the h2 element exists in the DOM since we are saying that the debugger should only pause the test only if the h2 element exists in the DOM.

Now, let’s run the test.

As you can see, now the debugger only pauses the test after it gets the element and makes sure that the element does exist in the DOM; otherwise, it will throw an error.

Let’s fail the assertion on purpose and see if the .then() function runs or not

it('should only pause when the cy.get() function finishes executing', () => {
  cy.visit('https://ecommerce-playground.lambdatest.io/')

  cy.get('[data-cy="some-selector-which-does-not-exist"]')
    .should('exist')
    .then($h1 => {
      debugger
    })
})

Running the test:

As you can see from the screenshot above, the debugger will never pause the test since the assertion has failed and the .then() block did not have a chance to be executed.

Run your Jest testing in massive parallel across multiple browser and OS combinations with LambdaTest, Read more!

Using the .debug() method for Cypress debugging

The .debug() method is a shortcut for Cypress debugging, which you can chain to every other Cypress command wherever in your tests.

It will expose some details in the browser’s console when the .debug() function triggers:

Command Name: the name of the last command invoked before the .debug() triggered.
Command Args: the list of arguments passed to the last method before the .debug() invocation.
Current Subject: a new variable will be created inside the browser with the name subject, which you can interact with using the browser’s console.

The subject variable is the return value of the Cypress command and can be interacted with by using the browser’s console.

Let’s try it out. In this example, I will get the first h2 element on the page.

it('should pause the test by using the .debug() command', () => {
  cy.visit('https://ecommerce-playground.lambdatest.io/')

  cy.get('h2')
    .should('exist')
    .debug() // debugger
})

Execution:

In this case, the subject variable represents the return value of the cy.get('h2') command, which means the subject variable is an h2 element.

When we run the subject.text(), this will give us the text content inside the h2 element.

Using stack trace for Cypress debugging

A stack trace shows a list of method calls that lead to the exception being thrown, together with the filenames and line numbers where the calls happened.

Cypress also translates the stack trace so that the actual source file is shown along with its line numbers instead of the file loaded by the browser.

The Cypress console could be very useful whenever you face an error, luckily, most of the Cypress errors are well explained, and you can easily understand what is going on by simply reading the stack trace.

You can also integrate it with the VSCode IDE to jump right to where the error was thrown and shown in the stack trace.

For example, let’s introduce an error by trying to get an element that doesn’t exist in the DOM

it("should throw an error", () => {
  cy.visit("https://ecommerce-playground.lambdatest.io/")

  cy.get("some-selector-which-does-not-exist").click()
})

Running the test:

As you can see, Cypress does a great job explaining why and where the error happened.

AssertionError: Timed out retrying after 4000ms: Expected to find element: some-selector-which-does-not-exist, but never found it.

If you click the “View stack trace” button, you can see the file name in which the error was thrown.

If you click on it, it will ask you to select your IDE to open it. You can choose VSCode from there. If you can not open it, go to the Settings tab -> Device Settings -> External Editor -> Visual Studio Code or your preferred IDE.

Now, if you click on the link on the stack trace dropdown, it will automatically open that file and navigate to that specific line where the error was introduced.

This is a very good feature of Cypress UI automation tool, helps you easily spot errors and locate where the error happened.

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

Using logs for Cypress debugging

Using logs or console logs is another way to debug your code and get an understanding of what is going on when executing tests.

There are two different commands that you can use for logging outputs inside of your browser’s console, which is the cy.log() and the conventional JavaScript console.log() function.

Using Console log

Since all Cypress commands are asynchronous and will be enqueued for later use, you should never assign returning values of any Cypress command.

If you want to console.log() a returning value of any Cypress command, you should do so inside the .then() function.

If you log a returned value from a Cypress command, it will be logged in the browser’s console, but the value will be just a Cypress Chainer Object.

it('should not return the h2 element', () => {
  cy.visit('https://ecommerce-playground.lambdatest.io/')

  const h2 = cy.get('h2')

  // do not do this, the value will not be the actual "h2" element
  console.log(h2)
})

This is the result that you’ll get, which is not very useful.

If you want to log the return value of any Cypress command, the right way to do it is by logging the value inside of a .then() function. This way, you will get the actual element after you log it.
This is the right way to do it.

('should return the actual h2 element', () => {
  cy.visit('https://ecommerce-playground.lambdatest.io/')

  cy.get('h2').then($h2 => {
    // this will log the actual value of the "h2" element
    console.log($h2)
  })
})

If you want to log the text of the element:

it('should return the text of h2 element', () => {
  cy.visit('https://ecommerce-playground.lambdatest.io/')

  cy.get('h2').then($h2 => {
    // gets back the text inside the "h2" element
    console.log($h2.text())
  })
})

The result in the browser’s console is the text inside of the h2 element.

Using the Cypress log command

Cypress automation tool provides us with another useful command that will help us log outputs inside of Cypress’s dashboard logger.

You can use the command by running cy.log() anywhere in your code.

If you want to log the output of a Cypress command, just make sure you do it inside the .then() function since Cypress commands are being enqueued and not instantly executed.

The difference between the regular console.log() function and the Cypress log() function is that the Cypress log() function will log the output inside of the Cypress console, but the console.log() command will log it inside of the browser’s console.

it('should log the return value inside of the Cypress console', () => {
  cy.visit('https://ecommerce-playground.lambdatest.io/')

  cy.get('h2').then($h2 => {
    cy.log($h2.text())
  })
})

The result in the Cypress console:

Using .pause() command for Cypress debugging

Cypress exposes another command which helps in pausing the test execution and making it easily debuggable, you can then manually start the test again and resume executing Cypress commands.

The .pause() command is also a Cypress chainable and can be chained with any other Cypress command.

Cypress.pause() example of use

it("should pause the test", () => {
  cy.visit("https://ecommerce-playground.lambdatest.io/")

  cy.get("input[name='search']")
    .first()
    .should("exist")
    .and("be.visible")
    // pauses the command execution
    .pause()
    .type("Iphone 12")
})

In this section of this tutorial on Cypress debugging we are getting the input elements in the DOM, which has a “name” attribute of “search,” and we are selecting the first one by running the .first() command.

And we are asserting two assertions on them; after that, we are typing something inside of the input, but just before typing the input, we have run the .pause() method.

The code will run the first three commands and pause before running the fourth and final commands.

Running the test:

As you can see, a new button has appeared on the top of the Cypress console, and also, we can see in the final output of the logs it is written - pause, which is caused by our pause command.

Now, if we press the play button, the test will resume, and the commands will resume executing again.

Resuming the test execution:

The test will resume, and the last command will then be executed. Finally, the text will be typed inside of the search input.

[Bonus Tip] How to reduce type errors in Cypress?

I will give you a bonus, this one is not for Cypress debugging but for reducing and spotting errors inside of your application before running the tests, and it will provide you with a faster development pace.

Use TypeScript

TypeScript is a programming language that enables developers to write code in a type-safe way. Since Cypress ships with the official type declarations and is strongly typed, it will be easier for developers to spot and find type errors before running the tests.

Install TypeScript

Install typescript by running the following command.

Note: TypeScript 3.4+ is required to be used with Cypress.

Create a tsconfig.json file inside of the cypress folder with the following configurations.

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["es5", "dom"],
    "types": ["cypress", "node"]
  },
  "include": ["**/*.ts"]

Adding types for your custom commands

It is also important for you to add types for the custom commands that you will create and use throughout your tests and Cypress allows you to do that.

Let’s say you have the following command.

Cypress.Commands.add("login", (email, password) => {
  /**
   * Login to the application
   * With Cypress
   * ...
   */

  return "{ ... }"
})

If you don’t declare the types for the login custom command, you will get a TypeScript error instantly, so let’s go ahead and create the types for it.

Inside your support folder, create a file with the name index.ts and add the following code.

// cypress/support/index.ts
declare global {
  namespace Cypress {
    interface Chainable {
      login(email: string, password: string): string
    }
  }
}

Now your Cypress tests should be able to work with TypeScript perfectly. If you are still getting errors, restart the TypeScript server by pressing the Ctrl+Shift+P on Windows or CMD+Shift+P on macOS and type > in the beginning and search for >TypeScript: Restart the TS server and press it. This will restart your TS server and load the new configurations.

Now you will see an autocomplete option for all of the Cypress commands.

You will also see an autocomplete option for your custom commands.

To get accurate results, you must run Cypress tests on real browsers and OS. The best way to do this is by using LambdaTest’s cloud-based automation testing platform. Accelerate your go-to-market delivery by performing Cypress parallel testing on 40+ versions on the latest across Windows and macOS without compromising accuracy.

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

If you’re a developer who needs to perform Cypress end-to-end testing for your app and you’d like to get an overview of everything Cypress has to offer, the Cypress 101 certification is for you.

Test your website or web app online for iOS browser compatibility. Perform seamless cross browser testing on the latest iPhone tester Simulator. Try for free!

Conclusion

In this Cypress debugging tutorial, we have discussed the best ways to debug Cypress tests easily. Cypress UI testing is an excellent framework for validating your front-end applications. It provides us with many great features to debug our test suites easily.

Here are the different ways to debug your Cypress tests:

Using a debugger.
Using .debug() Cypress command.
Using the stack trace.
Using logs console.log() and cy.log().
Using the Cypress .pause() command.
Using TypeScript to reduce type errors.