Test Automation with Cypress

Cypress is an open-source framework for creating end-to-end tests and component tests for web applications. It runs on Node.js, which means that the code for our tests is written in JavaScript (JS). The tool offers a rich array of possibilities for creating automated tests. By using JS, we can write our tests in a simple, short and legible form, using one of the most popular programming languages in the world.

Cypress also has a built-in tool for debugging tests in real time. While the test is running, the debugger shows each phase of the test is currently running and what the result is. When the test is finished, we can go to any step and review what happened there. This provides both incredible convenience and freedom in writing tests. It also allows us to change the test code and check the results in real time.  

Folder Structure  

After creating a new project, Cypress will automatically add suggested folder structure. By default, it will create:

• Fixtures - here we can place static data that we will use during tests,  
• E2E  (stands for end to end)- by default Cypress is looking for tests here, we can put more directories here to separate files,  
• Plugins - are used to change Cypress behavior, they are run before each test file,  
• Support - used to define behavior, which is common for all tests and should be run before tests.  

The Use of Additional Testing Libraries  

The Cypress stack uses some popular test libraries for assertion or report generation. These include:

• Mocha - allows you to build a JUnit or a TeamCity report. There are plenty of plug-ins for the Mocha library, so we can be sure to generate the report in the format we need,  
• Chai - a built-in library for assertions,  
• Sinon - a framework whose methods Cypress uses in cy.spy, cy.stub, that is monitoring function calls.  

There are also several plug-ins that are not built-in, but they are worth installing:  

• Cypress-recurse - a plugin that makes it easier to write recursive functions,  
• Cypress-tab - a plugin that adds the ability to send the 'TAB' key to the browser,  
• Cypress-plugin-snapshots - this plugin for visual testing compares the baseline and the current images side by side if pixel difference is above the threshold.  

Downsides of Cypress

Cypress is undoubtedly a great tool for testing the front-end; however, it is not without flaws.

Difficulties with iFrames  

Working with iframes is indeed difficult. Cypress has many more problems than Selenium. We have the option of using additional libraries to help work with iframes, such as "cypress-iframe", but these solutions do not always work properly.

Only Supports JS/TS

This is not a disadvantage for everyone. I put it as a disadvantage because Selenium WebDriver supports virtually all programming languages. Another thing worth mentioning is that JS is often a more difficult programming language for beginners.

Writing and Organizing Tests  

The test interface, borrowed from Mocha, provides describe(), context(), it() and specify().

context() is identical to describe() and specify() is identical to it(), so any terminology will work.  

Cypress also provides hooks (borrowed from Mocha). These are helpful to set conditions that we want to run before a set of tests or before each test. They're also helpful to clean up conditions after a set of tests or after each test.  

To run a specified suite or test, add .only() to the function. All nested suites will also be executed. This gives us the ability to run one test at a time and is the recommended way to write a test suite.  

To skip a specified suite or test, add .skip() to the function. All nested suites will also be skipped.  

Automatic (A)waiting  

Cypress automatically waits until an element reaches the state we expect. This isn’t so obvious in the world of automated testing.

In cases of assertions (for example .should('be.disabled')) Cypress will automatically wait for a certain amount of time until our element reaches the expected state, so we don't have to worry about specifying precisely when the element should meet the set requirement. Many functions have built-in implicit requirements, for example .get() and .find() expect an element to exist in the DOM, .type() expects an element to allow typing, and .click() an element to interact with. The above requirements are covered by automatic waiting, for example, when using the .click() function, Cypress makes sure that an element can be interacted with. If not, it will wait until the element: is not hidden, is not covered, is not disabled, is not under animation.

Example test

With all this acquired knowledge, it’s time to write the first, simple test. We will be using an example app used to showcase Cypress.io testing.

describe('My First Test', () => {  

  it('Go to the get page, check correct url and visibility of the button’, () => {  

    cy.visit('https://example.cypress.io')  

    cy.contains(‘get’).click()  

    cy.url().should('include', '/commands/querying’) 

    cy.get(‘#query-btn’).should(‘be.visible’) 

  })  

}) 

In this test, we checked the correctness of a predefined URL when we clicked on a link that takes us to a new page, and we also checked that the element expected on that page is visible.

Closing Words

In today's article, we introduced what Cypress is and its advantages and disadvantages. We encourage you to check this tool out for yourself. If you are thinking of using Cypress commercially, pay attention to the disadvantages specific to the framework, especially if you have an application that uses iframes a lot. It's worth checking whether Cypress can handle this situation. If, on the other hand, you think you don't have a need for a new tool in your project, then consider thinking about learning the tool in order to expand your skills. In other cases, we recommend giving it a shot in your web projects.