Optimizing Test Automation with a Reusable, Component-Based Approach

Let's pick up any modern web application and if we see inline technologies on development, most are based on Angular, React, Native, Vue, etc. Majorly all are based on a Component-based approach. The main advantage of having this is Code Reusability, Ease of maintenance, single-point change, etc.

What if We try to follow the same approach for our Test automation framework as well? Yes, Component Based Framework.

What can be our approach to make it possible?

1. First, go through the application which you are planning to test. This would be really required to make our framework more robust.
2. Identify the UI components which are common across multiple pages. It can be tables, Buttons, Tabs, Menus, Headers, Navigations, Forms, etc which you can see at multiple places.
3. A thorough study of components, locators of components on multiple pages, their behavior with user interactions. These will be the key point to implement any component.
4. Once you identified the Component and its behavior, we will plan our implementation for each component.

How my One component will look like?

Each component will have required locators/selectors and Actions applicable to that component.

Eg. — Table Component

1. Locators: Keep your selectors/locators for Rows, Column Names, Headers, Buttons on the table if present, etc.

2. Actions: For a table, there can be multiple actions like — Get Row counts, Column Counts, Get row data, column value for a particular row, perform right-click on Row No, Perform Click o row for which particular set of column values match, etc. For your application, you can identify more actions as well.

Our component layout may look like below.

How I can Utilize the above Component?

The next question that comes in Our mind is, How I am going to use this component and How it would be useful over a pure Page Object Model.

Let's assume — we have an application with two pages, say Page 1 as Home Page and Page 2 as Landing Page. The home page has a table that contains all the records of a user-related to transactions (date, time duration, amount, actions for view, etc.) and the Landing page has a table with generic data of their Users, success count, links of Case studies, etc.

If we see the context of both the pages, the data will be different and use cases also. but underlying DOM might be the same i.e Table. In such a case, Instead of handling all locators and actions on both pages, We can utilize the TableComponent for both.

In the above pages, we directly used Table Component. Same way, You can identify a set of components for your application and can be reuse on multiple pages.

Advantages :

1. If any Locator is going to change or more actions are added to a component, we just need to update in one place, instead of checking in all the pages.
2. Code is reusable and easy to maintain.

I will recommend this approach for small applications. For very big applications, we might have multiple sub-products and separate dev teams as well. The structure of DOM might differ for each sub-product. In such a case, our Component may become very bulky and hard to maintain.

Happy Learning !!.