Want to work with Cypress automation tool?

Tips to improve your code’s quality & performance.

I had a fresh experience working with the ever improving Cypress. You will find below some newer / different approaches to work with Cypress.

You can find my earlier implementation here.

Linting:

We know that linters helps check the code statically for any smells. ESLint was our choice and it is pretty simple to set up.

Note that we have turned the lint off for JS files.

Pre-commit hook :

I prefer to have a pre-commit hook in order to avoid any secrets landing up in version control systems (VCS) or it’s history. Now that Hawkeye — which I had recommended earlier — has been deprecated, I chose Talisman.

I added its installation and configuration as a pre-requisite of the repository (specified in the README.md). In the root directory you simply need to run

sh ./scripts/setup.sh

which contains 👇

Seeding data :

This time, I did not have APIs to perform CRUD operations for seeding test data. So, I used a .sql file in the fixtures directory to achieve this.

Locating elements using XPath :

Sometimes it is not possible to have test IDs for all the elements. In such cases, you can use relative XPath using this plugin.

Take a look at the snippet here to get started.

Locating elements using RegEx :

At times, both CSS & XPath locators can inhibit a reliable interaction with an element. It becomes imperative to use IDs then. But if IDs are not plausible, RegEx comes to the rescue.

Checkout the example below :

cy.get(‘div[class^=Element]’).find(‘span’).contains(‘Read’).click()

In the example above, we are locating a div class that starts with a text “Element”. Inside it we locate a span which has a text “Read”.

Removing “data-test” ids from your production DOM :

It is well known in the Cypress community that “data-test” ids are a recommended way to locate an element. However, if your team uses them you must remove them from your production DOM. Otherwise your production DOM will be littered with “data-test” ids of no significance and make the DOM a little bulkier than needed.

If you need to run automated read-only tests (like for static website) on production (after every deployment) then you may choose to keep them.

Uploading files :

When you need to automate tests for file upload feature, this Cypress plugin can help out.

Waiting on API calls :

Generally, we use an element’s behaviour for waiting before performing the next step in the test.

Another possible approach could be, waiting on an API call. In my experience, it is quite a reliable way to match up the automation speed with the user’s behaviour.

Intercept the API by giving its relative endpoint. Wait for the request to trigger and then perform the next steps.

You can also configure it based on your needs, e.g. verify that the response code is 200 before moving forward.

cy.wait('@Upload').its('response.statusCode').should('eq'
200);

You can specify the endpoint partially too

cy.intercept('POST', `path/*`).as('Upload');

A parameterised relative endpoint is another possible implementation

cy.intercept('GET'
`</path/${parameterIfAny}>`).as('LoadDetails');

Assertions :

We know that Cypress integrates quite a few assertion options. I have generally found BDD Chai assertions to be quite self explanatory. This is how it looks :

cy.get(‘element’).children().should(‘have.text’, expectedCount);
cy.url().should(‘eq’, <location>);
expect(cy.get(‘element’)).to.exist;

Fail fast:

It is time as well as cost prohibitive to get slow feedbacks. What if it is a deal breaker even for one test to fail but you get feedback only after all tests run in vain?

In order to get quick feedback on your CI integrated automated tests, you can use this plugin. It can be configured easily as per your needs.

Right now, I am using the default configuration to stop the execution even if one test fails. It might evolve as our requirements change in the future.

Stay tuned for more!