Cypress : UI Automation standards at MiQ

As we grow with an increased need for automation, it’s very important to also have a standard practice for allowing new test cases to be added at ease. It’s as simple as saying, we need to also have SOLID principles for code structure, wherein, it should be easy to add, modify and scale automation. At MiQ, we have been focusing on using Cypress for our UI automation and we felt there is a need to provide a standard way to write tests.

This blog highlights the standard practices that are being followed by MiQ while writing Cypress tests.

Benefits of standardisation:

1. High scalability — Writing test cases becomes easier as one does not have to memorise cypress syntax and complicated xpaths.
2. Loose coupling with cypress — The wrapper functions enable us to move to different automation tools in the future with minimum effort.
3. Code reusability — Writing common actions in separate page function files instead of test cases increases the code reusability.
4. Low Maintenance — It is easy to identify which files to modify when elements on the application are changed.

What MiQ is doing differently with cypress

1. Avoid using classes and objects

Page Object Model is a very popular design pattern for test automation projects. However, we did not go for this approach as we feel there is a cleaner way of writing and maintaining your tests. Instead of maintaining classes we export functions directly. End result is that we don’t have unnecessary lines of code for instantiating objects as shown below:

Test script without using page objects.

2. Minimise usage of custom commands

Custom commands are one of the unique features of cypress. Custom commands are beneficial for automating a workflow you repeat in your tests over and over. At MiQ, we prefer to use functions to store repeating workflows instead of cypress commands. This gives us two benefits:

1. Cypress commands is a cypress-only feature. The more we use it, the more dependency we create on cypress and it will be difficult to switch to a different tool in the future.
2. There is an additional overhead for automatic code completion with cypress commands.

Page functions

In this approach, each web page in the application has its own independent javascript file. Let’s call it Page functions.

A page functions file serves two objectives:

1. Store the identification information of all elements on that page.
2. Stores the functions that perform actions on the page.

Javascript file resembling the “Add Employee” page on demo application

Folder Structure

Everybody knows that a good folder structure is important. A proper folder structure is especially needed when collaborating with others as it helps organise your code and improves findability. The value of a good folder structure increases exponentially with a growing codebase.

Fixtures: This folder comes with the cypress package and we are using it to store mocked API responses.

Integration: This is where our tests reside. We further break down our tests into component-tests and end-to-end tests.

Pages: We use this folder to store page functions. This folder can have sub-folders for each module in the application. For example — “action”, “admin”, “PIM” are different modules on the sample application that we are using.

For SPAs (Single Page Applications), we can use iframe names for the categorization logic.

Support: We are using this folder to keep our utils and constants.

Folder structure being followed at MiQ

Writing Test Cases

The objective of this approach is to re-use as much code as possible. Hence, we separate complex logic and validations from the test case. For example in the below image, element identification, as well as validations, are happening directly in the test case. This approach makes it difficult to comprehend what is happening in the test.

Code highlighted below can easily be converted into a reusable function. The test data that is being used can be the function parameters. This increases the re-usability and readability of the code.

Old approach

New Test case:

This is what we get after we break down test steps into smaller functions.

New test case after standardisation

Element Identifier

This file provides the abstraction for the Page functions. It provides the methods for identifying elements on the UI. We will be using external libraries to identify UI elements and

Element-identifier.js acts like a wrapper to hold the complex logic for identifying elements.

The main benefit of having this file is that one does not need to know the syntax of writing complicated xpaths, making it simple to write tests.

https://gist.github.com/ladvish/39681551df40ab3a392bffde1df8c6f8

Impact of standardisation at MiQ

We noticed significant improvements in the UI tests after standardising the UI automation framework. The major benefits were:

1. Onboarding new tests were relatively faster as most functions were reusable.
2. Code readability improved and it was easier for new team members to debug existing tests.
3. Maintenance time was reduced significantly. In case of any updates on UI elements on the application, we have to update only one file.
4. In one of the teams, the test suite size increased by 100% in a week’s time.