Web Frontend testing strategies with Cypress

A great technology that surpass Selenium in every possible way

In the past, I tried more than once to automate websites testing using Selenium. I always had to abandon the idea because I found the tests hard to write and the documentation not really clear on how to start.

This finally changed recently with Cypress.

Cypress has an excellent foundation and it’s not based on Selenium core technologies: instead it’s a new project based on Chromium foundations.

Cypress tests uses Javascript and testing frameworks like Mocha, Chai and Sinon. More informations here. If you already used testing frameworks on JS, you are basically at home.

Separate test logic from implementation details

One of the biggest problems of Frontend Testing is that, as time passes, tests starts to break up because the html, js and css changes and the tests selectors and logic starts breaking up.

My suggestion is to split the work this way: * a support class that implements all the asserts, the logic, and work with selectors * an integration class that only call the method from the support class to do all the work.

For example, the integration.js file will contain high-level functions like these:

it('Save Post', function () {
    var data = {
        title: 'New Post', 
        text: 'Lorem Ipsum'
    }
    
    // login with the backoffice user and go to the new post    
    Post.loginAndGoToNewPost('backoffice')

    // sets the data in the form
    Post.setPostData(data)
    // assert the data contained in the unsaved form
    Post.assertPostData(data)

    // saves the post and retrieves the id
    var id = Post.savePost()
    // go to the post detail
    Post.goToPost(id)
    // assert the data contained in the post is the same we wrote
    Post.assertPostData(data)
})

The support post.js file will contain all the low-level functions to work with a post.

Login

This point it’s explained at length in Cypress documentation at this page.

Containerize the application

The first step I do when I have to integrate frontend testing in a project, is to containerize the project with Docker. This way, I only need a docker-compose up command to start the web application with an empty database.

Database should be as empty as possible

The database should be also emptied of all the data. I usually leave a couple of users and very few data that I can assert.

For example, if I have 3 categories of users, the database should contain one user for each role and I save these informations in a fixture:

users.json

{
	"backoffice": {
		"username": "backoffice",
		"password": "backoffice001",
		"name": "Back",
		"surname": "Office"
	},
	"frontoffice": {
		"username": "frontoffice",
		"password": "frontoffice001",
		"name": "Back",
		"surname": "Office"
	},
	"user": {
		"username": "user",
		"password": "user001",
		"name": "Mario",
		"surname": "Rossi"
	},
}

Now, whenever I need to run a test with different users/roles, I can do something like that:

describe('Home page: ' + userType, function () {
    beforeEach(function () {
		// prepare fixture for all tests
        cy.fixture('users').as('users')

    });
    // iterate between all roles
    ['backoffice', 'frontoffice', 'user'].forEach((userType) => {
        context('User type: ' + userType, function () {
            it('Name and surname should be equal to the logged in user', function () {
                // Custom command that manages the login
                cy.login(this.users[userType].username, this.users[userType].password)
                // Visit home page
                cy.visit('/')
                // UI should reflect this user being logged in
                cy.get('#logged-user-name').should('contain', this.users[userType].name)
                cy.get('#logged-user-surname').should('have.value', this.users[userType].surname)
            })
        })
    })
})

Tests should never depends on previous tests

This is true for 99% of the testing frameworks, but it’s important to re-iterate it: A test should never depend on the result of a previous test.

For example, for a test that needs to tests the editing of a post shouldn’t depends on a post created from a previous test but it should create a new post and edit it.

The process can seems tedious, but it’s really important that every test can be executed in isolation. If your project permits it, you can use API calls to prepare and create content needed for the specific tests.

Run the frontend tests for each commit

Frontend testing are usually slower than normal tests and in a Continuous Integration context they are harder to integrate because they slow the build pipeline a lot. I also think it’s wrong to execute them only before a deploy because in frontend testing it’s really important to continuously find and immediately fix the regressions.

My general suggestion is to run the tests at each commit

If your CI setup doesn’t permit this, you can consider running the regression testing nightly on the latest ‘good’ build present in the system.

Tests must be 100% reproducible

Tests must be written in a way that, no matters how many time you repeat them, they always returns the same result.

This is one of the most important part of writing tests in general and it’s more important in Frontend Testing because they are much slower to execute and debug than Unit Testing and Integration Testing.

Imagine this scenario:

The Frontend Testing finds a couple of regressions and your team start analyzing the problem; after hours of hard work, they discover that the problem wasn’t in the source code but in the test code: The tests ‘randomly’ fail because they are not coded in the correct way. After this happen a couple of times, your team slowly starts to ignore all frontend testing regressions and also stops updating and writing them.

This is why it’s really important to start with a small but excellent test suite that will never fail for ‘random’ causes or timeouts.

After the team haves the grasps on how to build top-notch tests, the test suite can be expanded and can cover more cases.

Like lot of programming things, the expansions is usually exponential: The first couple of days are usually concentrated on a really basic test suite and the foundation classes that drives them, but after that phase the tests suite can expand faster.

When in doubt, check the documentation

Cypress technical documentation is excellent, and I highly suggest to read all the introductory articles; they are full of tips and high level suggestions on how to structure your test suite.