Why choose Cypress?

Why choose Cypress?

Comments 0 Comment

What is it?

Cypress (https://www.cypress.io/) is a quite new testing framework. It becomes very popular last year. Mostly among the front-end developers. It is not surprising when we look into the most interesting features of this library:

  • Modern UI with the ability to:
    • preview test execution,
    • time travel in test execution,
    • validate and debug the page during the testing.
  • The integrated mechanism for network call simulations.
  • All in one solution.

The new kind of UI is especially interesting because it gives plenty of useful functionalities.

It runs the test and let the developer see the progress and the changing state of the tested web page. It is very useful in the everyday job because it shortens the feedback loop.

Technology stack

Cypress works in a modern front-end development stack: Moch, Chai, Sinon, jQuery. It perfectly matches with the tools, which the developers usually use to write unit tests. Moreover, Cypress gives the opportunity to run full end-to-end tests and integration tests with mocking some part of the application. With additional libraries, it also allows executing front-end unit tests. It makes Cypress the complete testing framework for your applications. 

Benefits

Cypress is worth to include in our technology stack as a complete framework. That’s why we need to be aware, what benefits we could get when we start using it.

Great UI

It helps to create the test flow. Cypress UI let you verify the whole test step by step (line by line). When some line is not executed correctly, you can immediately check, what is wrong and what is the current status of the page.

Time travel debugging

Cypress UI let to move freely back and forth through all test steps (test code lines). It makes all investigations much faster and easier. You don’t need to hold on the whole test execution to check the particular step anymore. This is very useful in context with the next feature.

Test recording

When you execute tests, you can record the whole test execution path and preview it in the Cypress web application. It works fine also for remote test execution (i.e. for Continuous Integration pipelines). If you would want to use this feature on a big scale, you will have to pay for the Cypress cloud interface.

Easy debugging

Because tests are executed in the same context as a tested application, we can easily debug the target application using Chrome Developers Tool.

No waiting

Using Selenium (the most popular library to end-to-end test automation) we need to ensure, that each HTTP action is finalized when we want to test the page fragment depending on the result of such query. Cypress automatically detects all JS work and automatically applies to wait, so we can forget about it. This is very useful to make tests more readable and reliable.

Great documentation

This point is very important for every library. Good documentation can help users with various problems and make the learning curve less steep.
These are only the most important advantages of this library. Generally, from the business perspective Cypress can improve the following areas:

  • test maintenance time – using convenient debugging and test recording,
  • test writing time – thanks to good documentation and no waiting
  • ability to share the responsibility of creating tests with front-end developers – because of the common technology stack

Problems

Beside of all these advantages, the Cypress is not free of the downsides. Let’s have a look for this side.

Works only with Chrome browser

It doesn’t let you start testing on multiple different browsers. If you use: the newest browser features, you need to support old or exotic browsers, then you probably need to test your application on different browsers and this is the limitation for you. But testing on Chrome is much better than not testing at all. 🙂

“Cross browser testing is now a front and centers major focus here at Cypress” – information from the roadmap (https://github.com/cypress-io/cypress/issues/310)

Only a single domain

One of the main restriction to Cypress tests is that they can be executed only in a single domain per test. In addition, tests can’t be related to each other, so it is not possible to perform cross-application testing if they are hosted on different single-level domains. Fortunately, you can freely move from subdomain to subdomain.

No support for iframes

If you use iframes in your application, then you can’t test it in Cypress. Yes, that is the pain, but this is related to the Cypress architecture. It is also already on the roadmap (https://github.com/cypress-io/cypress/issues/685)

No mobile testing

You can emulate smaller screens for testing, but you can’t use mobile actions like a swipe or resize.

Automation (integration with CIs)

We can easily integrate the various Continuous Integration tools. It is easy because it needs only to run several commands in console. Here you can find examples of configuration for some CI tools: https://docs.cypress.io/guides/guides/continuous-integration.html#Examples

Price calculations

The paid plan is required only when you need to use a big number of test recording.

The problem with the price is that it increases depending on the number of tests. You can estimate the required number of test recording using the following calculation:
[number of merges to develop branch per day] * 30 days * [number of projects] * [average number of tests per project]
We assume that tests are recorded on CI environment after each merge to develop branch. The example calculation:10 merges * 30 days * 10 projects * 50 tests = 150 000 recordings which mean, that we need to pay for the highest tier.
We can also decide on the other test execution strategy, but when each test execution recording costs something, then we need to consider when we want to use it. We can assume, that it is worth to record it only in remote environments when the tests are executed automatically.

Learning resources

Final recommendations

When we already know the features and problems around the Cypress library, we can definitely say that this is a framework designed for developers and they will enjoy it the most. So, if the developers write end to end tests in your team, then they should evaluate adding Cypress to your tech stack. If your end-to-end tests are created and maintained by a separate QA team, it is worth to stay with other tools like Selenium. It is well known by QA engineers and more powerful in case of integrations (see http://www.diwebsity.com/2019/07/13/how-to-deploy-ionic-to-google-play-store/).
Beside of the above points, it is worth to keep an eye on the development of Cypress, because when their authors fix all early age problems, it becomes a very attractive competitor on the market of testing tools.

Examples

Here you can find my examples of using the Cypress with some test pages: https://github.com/suvroc/cypress-demo
You only need to execute the following commands to see all the power of this library:
npm inpm cypress install npm run test
This is a basic summary of the Cypress library. It is definitely worth to check if you create end-to-end tests frequently.