My impression after working with Cypress

Several months ago, I started working with Cypress to write end to end tests. I joined the Test Automation team with an already-set-up framework, so I started out doing small refractors to get used to its flavour and the structure of the project itself. It was also my first introduction to JavaScript which I found quite flexible and quick to learn. 

After a couple of weeks of training, I could say I was familiar enough with the core functionalities of Cypress, so I thought it would be good to further my learning by making an aside project from scratch. More specifically I set up a framework to test some Netflix functionalities. The reasons? As it turned out with web scraping, I suspected I would end up researching more about this test framework just out of pure need. On the other hand I was curious about the setup of the whole framework; even if it was rather a simple project it proved a very useful experience. Here’s what I can summarise out of my experience: 

What is Cypress?

First of all, a critical question to answer is what is cypress? It’s a testing framework but certainly it’s necessary to know what differentiates it from other testing frameworks. 

During my learning period, it didn’t come as a surprise to find out cypress was fairly popular amongst Test Engineers, but it did surprise me that front-end developers themselves where specially fond of this tool. And this was due to the fact that it was designed by front-end developers with the aim of testing their applications in a fast way as they developed.

In a broad sense, one could say Cypress is a testing framework that targets end to end testing (though it’s also fit for integration and unit testing) in web applications developed specially with Angular and React.

You need to know a bit of JavaScript

Unlike Selenium, Cypress is not a multi-language supported framework. In only runs with JavaScript. And this makes plenty of sense if we take into account that JavaScript dominates the modern web applications’ front-end and that Cypress was created by front-end programmers. Moreover, Cypress is built on top of Mocha, which is  another JavaScript test framework. So for now, Test Automation engineers aiming to implement a Cypress framework will need to know their deal of JS. 

Cypress’ architecture removes part of the complexity

It seems to be fair to compare cypress with Selenium architecturally given the popularity of the latter in the Testing field. Also, I have been a selenium user for multiple purposes, so I have experienced in first person one significant difference in the architecture of both tools. 

Selenium, like other tools, runs outside the browser. This means our code serves to execute commands on the browser by means of a driver that ultimately reach the application under test. This adds extra complexity to the project since by using a Browser driver (or several) you have to deal with further browser configuration.

Cypress on the other hand, runs in the browser itself acting directly on the application under test. By removing the driver layer from the framework we are able to understand better wether failures are due to our application or to the tests itself. 

Another interesting characteristic is that Cypress has native access to the application under test thereby enabling developers to alter the state of their application or the browser from the test code instead of having to modify the application itself for a given test.

An amazing UI for debugging and time traveling

Yes, Cypress is cool, but its debugger was the jewel in the crown for me. And yes, I’ve also mentioned time traveling, before you think I’m mad let me explain. 

When you open Cypress its GUI pops up. A user friendly-designed interface with a “main menu” where you can choose which test suites to run. And when you run the tests the browser pops up showing you the view of all the steps executed by each test in real time and how cypress interacts with the application UI. Put simply, running your test with Cypress is also debugging them. From start to end, you can see step executions, network requests, page loads, assertions, etc. 

When the test fails or encounters an error, it highlights the step in red with a verbose error message. But that’s not all; along with the test fail you get a snapshot of the application UI in that very step. And that’s what I meant by time travelling: not only you get a snapshot of the moment of the test fail or error but at every step of the execution! While tests are running you see in real time how cypress interacts with the application. 

And once the test execution has finished, you can hover over every step depicted in the UI and you will see the UI at the exact state of the moment corresponding to the given step. Therefore you can perform a quire complete post-mortem analysis of your tests.

Conclusion

Altogether, Cypress seems to be an extremely promising tool for test automation in the scope of webApps. The reduction in complexity, along with the remarkable usability of its debugger, makes Cypress, in my humble opinion a strong candidate for modern webApplications. 

If you’d like to see the automation framework I setup with cypress for Netflix, you can find the link to the gitHub project it in my portfolio.