Cypress Automation Tutorial: Streamline Your Web Automation Testing

 

Why you should switch to Cypress for modern web testing?

“I think you’ll agree with me when I say…Test your code not your patience”

So, What I mean with the above line is that we are in an era where the web is evolving extremely with the deployment of angular.js, react.js, Vue.js and p5.js based web applications. These modern web applications are responsive, communicative(using chatbots) and built on top of material design.

We as software automation engineers are traditionally following the approach that has been started a decade ago. Yes, you got it right! I am talking about selenium here. Also, ten years back web wasn’t the same as it is today.

Since then web has evolved much, hence the testing should too!

Testing is one of the critical processes in application development. The success or failure of the application entirely depends on it. However, website testing is totally different from conventional software testing. Following are some factors that could be a big hurdle to the testing efforts and make web testing more challenging for the testers.

Challenges in Modern Web Testing:

• Dealing with XHR calls and web services
• Short deployment sprints, and major time involved in testing
• Security of data
• Very expensive to maintain due to lack of infrastructure for testing
• Dynamic behavior of applications due to modern development frameworks
• Many more yet to come in the future…

These are some problems associated with selenium. Selenium has been a major player in E2E web application testing for a decade now. But the modern web is different today, in order to overcome these shortcomings of selenium cypress comes into the picture here.

Why Cypress?

Cypress is a JavaScript-based end-to-end testing framework that doesn’t uses selenium at all. It is built on top of mocha which is again a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun.

Cypress also uses Chai a BDD / TDD assertion library for node and the browser that can be delightfully paired with any JavaScript testing framework.

Well, the developer of Cypress.io Brian Mann, through a survey collected data on testing challenges and addressed most of the shortcomings by developing Cypress. Although Cypress has many handy advantages I want to highlight only those that I found fascinating.

Automatic Waiting - Cypress automatically waits for - the DOM to load, the element to become visible, the animation to get completed, the XHR and AJAX calls to be finished and many more. Hence, no need to define implicit and Explicit waits.

Real-Time Reloads - Cypress is intelligent enough to know that after saving your test file(xyz_spec.js file) you are gonna run it again. So Cypress automatically triggers the run next to your browser as soon as you press CTRL+S to save your file. Hence, no need to manually trigger the run.

Debuggability - Cypress gives you the ability to directly debug your app under test from Chrome Dev-tools, It not only gives you straightforward error messages but also suggests how you should approach them.

Some more Advantages of Cypress:

Fig 1.0: Cypress Features

To have more insight into Cypress's Advantages over other automation tools, please read Cypress Advantages

What makes Cypress Different?

Architecture - Most testing tools operate by running outside of the browser and executing remote commands across the network. Cypress is the exact opposite. Cypress is executed in the same run loop as your application.

Works On Network Layer - Cypress also operates at the network layer by reading and altering web traffic on the fly. This enables Cypress to not only modify everything coming in and out of the browser, but also to change code that may interfere with its ability to automate the browser. Cypress ultimately controls the entire automation process from top to bottom.

New Kind Of Testing - Having ultimate control over your application, the network traffic, and native access to every host object unlocks a new way of testing that has never been possible before. Instead of being ‘locked out’ of your application and not being able to easily control it — Cypress instead lets you alter any aspect of how your application works.

Test how your application responds to errors on your server by modifying response status codes to 500 so that timers or polls automatically fire without having to wait for the required time in your tests.

Shortcuts - Cypress prevents you from being forced to always ‘act like a user’ to generate the state of a given situation. That means you do not have to visit a login page, type in a username and password and wait for the page to load and/or redirect for every test you run. Cypress gives you the ability to take shortcuts and programmatically log in.

Shift left paradigm in Cypress

Installing Cypress

Installing cypress is a fairly easy task. The only thing you need to have is node.js installed in your machine and then it’s all about two npm commands -

1. npm init

2. npm install cypress --save-dev

The first command will create a package.json file and the second command will install cypress as a ‘devDependencies’ array in your package descriptor (package.json) file.

Installing Cypress will take around 2 to 3 mins based on your network speed

Cypress has now been installed to your ./node_modules directory. Once you have done with the installation part, you are gonna open Cypress for the first time by executing this command at the location where you have your package.json file -

./node_modules/.bin/cypress open

To view the full installation video click here. This will open cypress GUI like -

Fig 1.1: GUI-based Cypress Test Runner

Cypress comes with its own folder structure, this folder automatically gets generated when you open Cypress for the first time at that location. It comes with ready-made recipes that show you how to test common scenarios in Cypress.

Fig 1.2: Cypress folder structure

We keep our test data in JSON format inside the fixture folder and writes test inside the integration folder following the same naming convention. Any custom command will come under the support folder.

Writing Your First Test using Cypress

Let’s create a new file kitchensink_spec.js in the cypress/integration folder. Open up your favorite IDE and add the code below to our kitchensink_spec.js test file.

/**
	* @author Shivam Bharadwaj
	* @description Cypress Demo
	*/
	//This is where your test suite starts
	describe('My First Test', function () {
	//This function will execute before each test (i.e it())
	beforeEach(function () {
	//Visiting the url
	cy.visit('https://example.cypress.io')
	})
	//Here you actually writes your test (it() is similar to @Test annotaion of TestNG)
	it('Visits the Kitchen Sink', function () {
	//Click on type button
	cy.contains('type').click()
	// Should be on a new URL which includes '/commands/actions'
	cy.url().should('include', '/commands/actions')
	// Get an input, type into it and verify that the value has been updated
	cy.get('.action-email')
	.type('[email protected]')
	.should('have.value', '[email protected]')
	})
	})

Code Explanation -

• Line 7 is creating a test suite with the name ‘My First Test’. 
• Line 10 is creating a function that runs before each test. 
• Line 12 with the simple cy.visit command passing the URL we want to visit. 
• With line 16 we are actually writing a test having the name ‘Visits the Kitchen Sink’ 
• And inside it at line 19, we are kind of making an assertion first, and then if DOM contains a ‘type’ word on UI it triggers a click event on it.
• At line 22 we are verifying that after clicking the new URL should contain /commands/cations. 
• Finally in line 25 to 27 we first finding the element by its class name, typing [email protected] in it and finally verifying that the correct value is typed.

To view the short video of the code click here

Output -

Wow!! It took only 7.89 seconds for the application to load, type some values and verify the assertion. It’s incredible!!

Fig 1.4: Console output

using cypress we can automatically travel back in time by just hovering over the event within our application under test in such a way that it takes you to that moment where the application was at the time of the event triggered. But as we hover over the CONTAINS, Cypress reverts back to the URL that was present when our snapshot was taken.

Notice there is also a funny looking Log called: (PAGE LOAD) followed by another entry for (NEW URL). Neither of these was a command that we issued rather Cypress itself will log out important events from your application when they occur.

As you can see this is the console view at the bottom of the image(Fig1.4) where you can find all the information about the event like command, selector, value, matched elements, and yielded.

Congratulations!!! You have tested your app with Cypress.

Conclusion

Hence, we might think to switch our tactics and use Cypress as our primary E2E tool. It works as expected and makes our lives a lot easier.

I have used Cypress way too little to like it very much and think this is the tool we required.

In any way do try Cypress.

To know more about cypress refer to the links below -

References

• example source code
• Cypress.io documentation
• https://github.com/cypress-io/cypress

Guest Author:

Shivam Bharadwaj

Say Hi on Twitter