Reason why Cypress test are getting unproductive

Cypress has been favorite automation tool among QA community. However, not all teams are able to harness cypress to its full potential. Cypress philosophy is quite parallel to the traditional automation tools. Though the cypress adoption rate is high, the ROI is still a concern. This content is purely focussed on the pointers which needs to be considered before practicing Cypress.

Cypress claims to be automation tool for modern day development practice , a one stop destination for all tests relevant to application. Development teams (QA+Developers) can harness the power of cypress tests arresting the classic challenges. Cypress also claims to offer features which are not available in traditional test tools.

Cypress is a Node.js server process, which means it uses the same thread as your application code which makes it more powerful to access all the native objects of the application. Teams hopping over to Cypress, just display a modish outlook have filed entirely in adopting cypress in its nativity. The lack of understanding cypress philosophy has led test developers to implement tests in traditional way. Any tool used provides better ROI when implemented the way it is meant to be.

Cypress.io adoption based on geography

CYPRESS SUPER POWERS

Other automation tools performs tests limiting itself to the UI layer of the application. However, cypress executes the commands from within the browser which bestows the tool with some super powers. Everything that happens within the browser can be captured by cypress, so application can never bypass anything without cypress knowing it. Browsers natively use Javascript, so Cypress makes use of this to its advantage and making the tests execution comparatively faster.

Cypress is a complete package, unlike selenium you will not be asked to install web-drivers separately. Most of the dependant libraries can be installed through NPM.

INSIDE OUT APPROACH

Commonly QA teams maintain and manage separate repository for E2E automation tests, this practise stems from past traditional automation tools. Implementing the same practice to Cypress may not help arrest the challenges of traditional automation rather it further stops you from harnessing the actual powers of Cypress. The test code should reside with the application code, this helps the unit tests and E2E tests to accomodate changes during the sprint thus enabling the story completion at all levels - development + Unit test +E2E tests.

Teams which are great in collaboration may not find it challenging to implement this practice. Developers and QA’s would collaborate over the story/feature. Feature branches are pulled out and changes are incorporated simultaneously.

A COMPLETE NO-NO

Cypress clearly discourage support to some tests, using cypress to achieve one of the below is not so good idea. Cypress is purely focussed to support only application development and nothing beyond that. 

• Web Indexing
• Crawling
• Performance testing (recently I have seen some things happening in this space)
• Testing external solutions

ADOPT PRINCIPLES

• Locators “  data-*  ”

Are you still competing in the “ID” v/s “CSS” element locator arena? Invest in collaborating with the UI colleagues and draw up an element locator strategy for your team. Encourage developers to use data-cy , data-e2e or data-testID attributes to achieve a fail proof element locator strategy. These locators remain static unlike ID or CSS which is subjected to change due to regular UI changes. Have a defined locator strategy helps arrest test flakiness.

If the application is designed to use data-* attributes, the selector playground in test runner automatically pick up the locator. Following the locator strategy, it’s advised to check the contents of the elements before performing the action.

• Command Retry 

Applications do not load all DOM elements at once, what id the cypress commands are getting executed before the DOM element is available for interaction?

shouldn’t we be injecting wait? -NO

let’s take an example

cy.get(’data-e2e=Like-btn’).should(’be.visible’).click()

If the button under action is not available yet then assertion will obviously wait, then cy.get() retries again. The cy.get() continues to retry until the element under action is available. The retires will go on until the timeout. 

• Asynchronous execution

Cypress is quick in test execution because the commands are executed in asynchronous pattern. What does it mean? It means the test commands are not triggered one after the other unlike other tools, the commands are triggered in parallel. In case you have to interact with an element which is visible after certain action, then its advisable to chain the action with cy.then() function rather than injecting wait. 

• Power of cy.intercept()

Interacting with DOM elements may trigger calls to backend. The automation strategy should make use of this for deeper and more solid tests.

Let assume, on click of submit button a POST call will be initiated 

In the above example, cypress will keep tab on the POST call mentioned within the intercept command. Once the call is identified, the commands embedded within the block will be executed.