For years now, Selenium has been setting the standard when it comes to automated testing of web applications. However, many test automation engineers emphasize that this tool cannot always cope with testing modern software – web applications with state-of-the-art front. Recently, Cypress, an end-to-end framework tool offering simple syntax and a low entry threshold, has started to gain popularity among testers. Is it a tool for everyone? Why should you perform end to end testing with Cypress? In what ways is Selenium still better? Learn more about which projects it is worth using these tools for.
- 1. Why is system testing important?
- 2. End-to-end tests vs other types of tests
- 3. Cypress – end-to-end testing automation framework
- 4. Software testing with Cypress: use of additional libraries
- 5. Cypress vs Selenium in e2e testing
- 6. Creating end to end test with Cypress
- 7. Advantages of performing e2e testing with Cypress
- 8. Cypress disadvantages
- 9. Summary: is Cypress an end to end testing tool for everyone?
Why is system testing important?
Many articles have been written to explain why software products should be tested and why software testing is important. It is crucial to maintain the right balance between the different types of tests and to perform tests at all levels during the software development cycle. It is worth mentioning on this occasion that it is harder to identify causes of defects reported only during E2E testing than those reported at the stage of unit testing. Development and testing teams should then go hand in hand to perform both low-level unit testing and high-level ones.
End-to-end tests vs other types of tests
The test pyramid shows the proportions that should be maintained between the different test types. E2E tests are at the top of the pyramid – the purpose of end-to-end tests is to check the overall performance of the software system (from beginning to end) from the perspective of an end user. End-to-end tests are the most time-consuming test types.
Read also: A minimalist software test case
Cypress – end-to-end testing automation framework
Cypress is an open-source framework for end-to-end tests and testing web application components. Created by frontend developers for frontend developers, it has also become popular among testers thanks to its simplicity and friendly debugger.
Its main advantages are its clear syntax and easy installation, after which we can write the first tests overnight and thus easily verify the functioning of the application. Cypress is characterized by fast writing and running tests while ensuring their reliability thanks to automatic waiting for elements on the page.
Software testing with Cypress: use of additional libraries
The Cypress stack uses several quite popular test assertion libraries for generating reports.
They include:
- Mocha – allows you to build a JUnit or TeamCity report. There are plenty of plugins for the Mocha library, so we will certainly be able to generate the report in the desired format.
- Chai – a built-in assertion library.
- Sinon – a framework whose methods Cypress uses in cy.spy, cy.stub, i.e. in monitoring or mocking function calls.
There are a few plugins that are not built-in, but I think they are worth installing.
These include:
- Cypress-recurse – a plugin that makes it possible to write recursive functions.
- Cypress-tab – a plugin that adds the option to send the ‘TAB’ key to the browser.
- Cypress-xpath – in Cypress we look for elements using CSS selectors; this plugin will allow you to use xpath.
Cypress vs Selenium in e2e testing
It’s not that some solutions are good or bad, but we all know that Selenium is somewhat dated and doesn’t work well for websites with a modern front, where elements in the DOM are dynamically converted instead of reloading the whole DOM from scratch. This is the biggest drawback of Selenium, and Cypress was created mainly to solve such problems, focusing on the stability of modern frontend application tests. Initially, Cypress was conceived to help frontend developers write integration tests, but today it focuses on end-to-end tests and component tests. Thanks to the transparent syntax, the tool has quickly gained the trust of many testers.
Selenium is advantageous when it comes to supported programming languages. It is available for Java, Python, C#, JavaScript and Ruby. By default, Cypress only supports JavaScript (as well as TypeScript, after configuration), which can be a problem if the right competences within a team or a company are lacking.
Selenium has been on the market for years and although it has a number of disadvantages, they are well known, and the Internet is full of tutorials on how to deal with them. Selenium has set a certain standard and led the way in automating web application tests over the years. But new times require new solutions, and Cypress is certainly noteworthy thanks to the transparency and ease of configuration I mentioned earlier.
Tests in Cypress are performed quickly and steadily, and writing them is, in my opinion, a pleasure (e.g. unlike Selenium, it is sufficient to create a locator and you can perform actions on the object – in Selenium, in order for it to work, you must have a locator and a Factory). It supports all major browsers, such as Chrome, Edge, Firefox, and even Webkit. Interestingly, we also have Brave to choose from, and the default browser is Electron. Support for these browsers is available in the package, so you do not have to take care of them, as in the case of Selenium. However, remember to update Cypress if you want to have access to the latest versions.
Creating end to end test with Cypress
To start the test in Cypress, we can use the standalone application (download it from the official Cypress.io website) or create a project via the npm command (after previous installation):
mkdir cypresscd cypressnpm initnpm install cypress --save-dev
After the first startup, the folder/cypress is created – and the following folders within:
- to store e2e tests,
- fixtures for any testalia,
- downloads, screenshots,
- support for various helpers.
So, we open the Test Runner, select the type of e2e tests and select the default browser:
npx cypress open
Then we create a new file firstSpec.cy.js in the folder e2e, and there we place the following code, which opens the page, enters the username and password, logs into the application, and then verifies the effectiveness of the login by checking the visibility of the item.
description('My First Test', () => {
it('Does not do much!', () => {
cy.visit('http://zero.webappsecurity.com/login.html');
cy.get('#user_login').type('username');
cy.get('#user_password').type('password');
cy.get('[name="submit"]').click();
cy.get('#account_summary_tab').should('be.visible'); })
});
You can run the test in the console using the command:
npx cypress run
or in the debugger:
npx cypress open
Advantages of performing e2e testing with Cypress
- Simple setup
If you’ve ever configured JBehave, you’ll appreciate the simplicity of installing Cypress and how quickly you can start writing high-end tests after installation. No other framework, even the most up-to-date e2e web test framework, can offer the same.
- Low entry threshold
Although Cypress works only with JavaScript, it is not an insurmountable obstacle for those who want to use it. I didn’t have much to do with JavaScript myself when I started working with Cypress. However, in order to start writing tests, learning the basic commands, the syntax of which is very simple and natural, is enough. The option to combine commands allows you to run them synchronically which makes the tests extremely stable (for example, click on a given input, clear its content, enter text, then click the button and see if the button has changed its text).
cy
.get('input-selector')
.click()
.clear()
.type('newText')
.get('button-selector')
.click()
.then(($element)=>{
cy.wrap($element).should('have.text', 'newText');
});
- Checking the condition of elements
By default, Cypress checks whether the item you are looking for is in the DOM, whether it is visible, and has finished the animations. This allows you to remove unnecessary code associated with waiting from the test, and if an element loads longer, you simply increase the timeout command for a given method. As a result, the tests are both legible and stable.
- Tools
One of my favorite features of Cypress is that it provides a number of tools which are useful in tests such as cy.fixture or cy.intercept. The former allows you to manage test data, whether it is a PDF that you want to upload to the application, or a JSON file with a payload to API or test data in the DDD approach. The latter allows you to capture network traffic and even mock backend responses. This is very useful when we are waiting for a response from an API to supply the front with data, or when an external supplier is not responding, and we want to mock its response.
- GUI Debugger
This tool shows that Cypress was written by frontend developers. It has a great user interface (UI) combining the option to run and debug tests. Creating snapshots of the application status after each action gives us the opportunity to “travel through time” and see various stages of our test. Access to development tools allows you to preview, for example, network traffic. All this gives us a set of tools necessary to look for errors.
Cypress disadvantages
Despite its many advantages, Cypress also has some drawbacks, and you cannot simply overlook them if you are trying to choose the best solution for the project.
- Test post mortem
I think everyone has experienced how tedious it can be to debug a test that does not pass in a CI/CD environment. Here, Cypress offers us a video recording, a screenshot, and an error message in the logs. While in many cases this proves to be sufficient, it can be burdensome when you want to trace network traffic. In Selenium, it was no better – my personal favorite is Playwright with its traces. By default, Cypress is a tool with GUI, and it is the easiest way to debug tests.
- Multithreading
Cypress boasts support for parallel testing. However, it is not enabled by default and requires a simple configuration in CI/CD. This way, you can create multiple containers – each of them will perform one test thread (similar to the Selenium Grid). Compared to Playwright, where the tests run in many threads by default, or nUnit, where such a configuration is one line of code, it is a jarring deficiency.
- Doubtful support for BDD
Cypress itself does not support BDD, but relies on external plugins based on cucumber-js. The officially supported cypress-cucumber-preprocessor is not developed anymore and we need to use various clones precisely selected for our specific version of Cypress.
Summary: is Cypress an end to end testing tool for everyone?
Testing of software with cypress has numerous advantages. Once decided to test software with Cypress, you will see for yourself that it reduces the time needed to write e2e tests thanks to its syntax and the tools it offers. Testing in Cypress is a pleasure and should not cause problems even for beginners. However, debugging errors or more complex configurations may be more difficult than we would like.
So, if we need to write a few tests for a given project in a short time, we can use Cypress. Its seamless configuration and simple syntax will mitigate your lack of knowledge of JavaScript. Simple things in Cypress are… really simple. However, if the project is more demanding, then the configuration of Cypress, the runtime or numerous plugins, which are not necessarily compatible with the latest releases of Cypress, will be more demanding. But if you are familiar with JavaScript, Cypress may turn out to be a new “go-to” solution for your project.
You can find a sample code on my GitHub.
- 1. Why is system testing important?
- 2. End-to-end tests vs other types of tests
- 3. Cypress – end-to-end testing automation framework
- 4. Software testing with Cypress: use of additional libraries
- 5. Cypress vs Selenium in e2e testing
- 6. Creating end to end test with Cypress
- 7. Advantages of performing e2e testing with Cypress
- 8. Cypress disadvantages
- 9. Summary: is Cypress an end to end testing tool for everyone?
QA engineer at Inetum, continuously improving his Java competence. Sebastian graduated from the Polish-Japanese Academy of Computer Technology. In his private life, he is interested in cars, board and computer games, and computer equipment.