Photo by Patrick Selin on Unsplash

One of the first challenges I faced when I started working at ASOS was using the Cypress.io framework to write the very first front-end (FE) automated tests for one of our solutions. Most of the experience I had was with Selenium Webdriver, which was an already established and well-known automation framework within the tech community.

As most QAs know, one of the pains of FE testing is making sure that the tests are stable and robust enough to handle the dynamic nature of web pages. It has been a difficult task even with some of the most powerful frameworks, so why would it be any different with Cypress?

Well… we’re about to find out as I’d like to walk you through some of the Cypress basics.

Thankfully, getting started with Cypress is relatively easy. The online documentation is very detailed, and I’d strongly suggest that anyone new to Cypress spends some time going through it before writing their first test.

Cypress.io project structure

We first had to set up a Cypress project, which typically looks something like this 👇

Cypress project structure

The project structure in Cypress is quite straightforward. All tests need to reside within the integration folder, otherwise, the Cypress runner will not be able to detect them. You can run tests either from the Cypress runner or using the command line.

You will also find two very important configuration files — package.json and cypress.json. Package.json keeps track of any new plugins added to the project, whilst cypress.json enables you to add configuration values and modify the default Cypress behaviour.

Two other folders that are worth mentioning are the fixtures folder and support folder. The fixtures folder usually contains fixed data (typically in JSON format) loaded from a file and while the support folder contains a default commands.js file that groups together reusable functions or methods. You can have multiple commands.js files in the same project.

Writing your first test

Cypress test example

In the test example above 👆, we’re attempting to click on the ‘clothing’ button on the ASOS landing page, if it’s visible.

1. The describe() is behavioural logic derived from the Mocha BDD interface and explains which feature is under test

2. The before() is a hook that contains logic that we’d like to run before the actual test

3. cy.visit() is a cypress command that navigates to a specific web URL

4. it() is a Mocha BDD function that provides details about what the test is doing

5. cy.get(‘data-cy=clothing_button’) locates web elements on the page and is the basic building block of any Cypress test. Further actions can be chained off this command

6. .should() is a BDD assertion that verifies whether the button is visible or not

7. .click() clicks on the web element located by cy.get()

What to keep in mind when writing your tests

We do love to follow best practice, and these are some of the things we suggest to keep an eye out for: