Cypress.io component design technique for React applications

Cypress is a game-changer in the Automation testing world, the way that cypress was built and its architecture allows us as testers to cover more scenarios.

Cypress is not Selenium; in fact, it is totally different. And the way to build and design a framework should be different as well.

The most famous design technique in Selenium is the page object model, and many testers use the same design technique with Cypress. Even that Cypress on their official website recommended us not to go with that approach. Check blog.

The main benefit of using the page object model Is to make the automation framework maintenance-friendly. We can define a specific page's selectors in a separate file and then use these selectors in our test cases.

The main two downsides using the typical page object model with cypress are:

• Page objects introduce an additional state into the tests, separate from the application’s internal state. This makes understanding the tests and failures harder.
• Page objects make tests slow because they force the tests to always go through the application user interface.

On the other hand, a React application is component-based, where a specific page will be built from a collection of components. And components in React can be used on different pages too. So if we want to use the page object model, we may define the same locator twice on different pages.

So having these two facts, At Vandebron, we came up with a new way to design our Cypress Automation framework by creating a separate JS file for every component in our application, inside a folder called components within our cypress project as below:

Having it built this way, we eliminated all the previous problems mentioned earlier; we are not adding any classes, and we are defining objects within our test cases. And the most important part is that we are following the way that cypress recommends it.

And after defining the component locators and actions, we can import them inside our test case and use them as below:

And as you can see, our test cases are readable for anyone! And if any locator changes in any of the components, we can easily fix it in one location and from the same file. And lastly, if a component will be used in different places, we can use the same code.

In the next article, I will talk about how we use Cypress in our manual testing during the sprint and how it saves us tons of time and effort.