Cypress – New way of E2E Testing

It’s a mad dog world out there. In an age where websites and web applications are getting more and more fancier and trickier and we have almost a new .js framework every month, testing these applications is becoming challenging too. Testing of these dynamic web applications, particularly the end to end testing is something that is a point of concern for many teams and product teams all around the world have been (and currently are) scratching there heads to find an optimum tool or solution that fits there needs and gets the job done.

 

Consider the test engineers. In this quickly changing and evolving landscape, they need to master the tools as fast as they can and implement the automation asap. Team, particularly in Agile teams, wrestle, to achieve a satisfactory level of test automation due to short sprint cycles and rapid deployment.On top of that, there are challenges to include the testing as a part of the CI?CD pipeline , because you know- everybody wants to do DevOps and having a fancy CI/CD pipeline is now a norm in every large or medium scale enterprise.

 

So major challenges that we, as test engineers face –

• e2e testing is painful. It is slow. It is brittle. It has ugly waits, flakiness and what not.
• Even if point is true, you cannot ignore it – not at all. It has to be there.
• Need to have a single point of testing – as a framework – for unit, integration and e2e testing- it is very hard to have these three under a single umbrella.
• Need to set up and start writing tests when you build your application locally with good TDD approach.
• Tooling language difference means not a good support system from developers – consider this – you backend is in Ruby, Front end uses React and you want to write test cases in Java. :Mind-explodes:
• Maintenance – once you write test cases/test automation scripts, the journey just starts. Due to constant changes in the UI due to requirements and re-design, you need to make to constant changes to your framework and oh boy – make one change and it wreaks havoc.

 

Wait we Have Selenium!!

Chances are if you’re working as a Test Engineer or even remotely connected to testing , you’ve heard this name. If you haven’t, well, then you’re living under a rock.

Selenium is the de-facto tool when it comes to automation of e2e testing scenarios. It has a good market demand, has been adopted by a lot of enterprise companies, has excellent community support and has support for almost all major languages. Selenium has a good adoption in the industry and well as within the QA community.

Since Selenium has a very active community, there are a lot of forks and wrapper around Selenium that cater to specific .js frameworks – for example we have Protractor, which is specific to Angular websites. It also gels well with many gherkin-based BDD language frameworks like Cucumber, Behave etc. Selenium’s biggest advantage however, is that there is a lot of cross-browser support. Same tests can be run across multiple browsers without any hitch.

 

BUT…

However, there is a lot of things that make tests with Selenium brittle. First of all is the browser-language dependency. On top of that, there is a specific executable drivers for browsers – there is one for Chrome, one for FF, one for IE etc. So there comes a three-way complexity where your code needs to be compatible with browser driver, which in turn needs to be compatible with the browser version. This dependency chain is very brittle- although it can be managed to a good extent with frameworks like Maven, but the baseline is that somewhere down the line it’s going to come and bite you in the bum.

Another downside of Selenium is that since it is all UI based, there is a lot of dependency on network calls, which you cannot modify. This gives rise to ugly waiting mechanisms being applied to scenarios – things like time.sleep() or driver.implicitwait are very common in test automation code.

Also due to the async nature of .js frameworks like Angular, Vue.js etc., there is a lot of code modification or async handling that you’d need to do from your own code side, which is not a healthy practice and adds to your lines of code – making the framework poor to maintain.

 

Here Comes Cypress!

 

Cypress is a JavaScript-based end-to-end testing framework that doesn’t use Selenium at all. So there is no dependency on the JSON Wire protocol or any specific browser driver (lol but it only runs for Chrome & Electron..). It is built on top of Mocha, which is again a feature-rich JavaScript test framework running on and in the browser, making asynchronous testing simple and fun. Cypress also uses a BDD/TDD assertion library and a browser that can be paired with any JavaScript testing framework.

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:

• • No dependency on the browser drivers.
  • No need to add any waiting – Cypress automatically waits for the DOM to load, elements to become visible, the animation to be completed, the XHR and AJAX calls to be finished, and much more. Hence, there is no need to define implicit and explicit waits.
  • Cypress bundles with a few familiar tools, such as JQuery and Chai. It also has lodash integrated.
  • Hot reloading – once you have added a test spec file , if you make and save any changes, Cypress will automatically detect it and start re-running your test spec.
  • Cypress takes snapshots while your tests run. Simply hover over commands in the dashboard to verify what happened at every step.
  • Unlike Selenium running outside of the browser and handling commands thrown at the network, Cypress runs in the same loop as the applications do, with the help of a node.js server.
  • It also has access to both front and back ends, so it can handle every event and web traffic to make better automation.
  • Good integration out of the box for most popular CI/CD tools.

However it’s not always a bed of roses. There are a lot of areas of improvement , missing features that we, as testers would love.

• • Support for Cross Browser integration – Cypress can only run on Chrome and Electron as of now. Support for FF is in pipeline but it has been stuck there for more than a year.
  • Functionalities like file-upload, window and iframe handling is something that is currently missing from Cypress.
  • Works mostly on CSS/Xpaths – so no extensive support for locators – if you’re coming from a Selenium eco-system.

 

Let’s see how Cypress is installed and we’ll run our first tests on Cypress.