Best Practices for Reusable Components

Reusable components are pivotal in enterprise application development, offering scalability, manageability, and flexibility. It is designed for reusability, capable of being utilized across various test cases. This is particularly useful when using the same steps again across test cases.

For instance, in a shopping e-commerce site, you can create four reusable components: one for logging in, another for product search, a third for purchasing, and the last for logging out. These components can be utilized individually across various test cases.

Reusing existing components enables developers to save time and effort by eliminating duplication and streamlining maintenance tasks.

Let's go through the key best practices of using reusable components.

1. While creating a new test case, the first thing to consider is reusability of its steps. If anyhow the steps in a particular process can repeat in another scenario, then we should avoid creating a new test case. Instead, we should create a new reusable component with repeatable steps and pass the dynamic input or output parameters for the created component.

For example,

Login Component: The login scenario is the most common process where we will be inserting URL, Username, Password and click on Login button. The credentials might change in that case to reuse such case we can have input parameters for this Login Component and all the data can be kept dynamic.

In a similar way there can be multiple processes which might repeat in the scope of testing. To enhance the reusability of such components we should avoid passing static data/recording dynamic object or texts.

2. Cover all parameters on a particular process

Suppose there is a form for creating an invoice the user will be inserting multiple data like Name, Supplier, supplier site, amount, Type, Item, etc. We can create separate components to cover all the possible parameters for the page. These components can easily be reused in other scenarios instead of creating new component for the same type of process.

Consider the page below - If it's not possible/required to cover all parameters in a single component, we can break the page into the parts and for different scenarios we can directly reuse I.e. call such component in the main test case.

The above component can be Segregated into

a. Requisition Header : A reusable component with steps to fill values such as Line Type, Item, Item Description, Category name, etc.

b. Delivery: A component with steps to fill values in the Delivery section of the form shown above.

So that in case there are more fields in the form these two components can be recalled and the efforts to record or create these steps will be saved.

3. How to decide if one should reusable component or add steps?

If you find few steps are going to repeat in any of the further process or can be part of any other reusable components, then instead of inserting steps through recording or keywords, create reusable components and call them with relevant data wherever required.

4. Keeping Components Simple - Simplify component implementation by using coding practices that make code clear and easy to understand for other developers.

5. Standardize Naming Convention – Ensure to standardize component names for clarity and consistency across projects and teams, reducing confusion and accurately reflecting their purpose and function.

6. Keeping components simple

Complex and opaque components hinder reusability and increase the likelihood of errors and technical debt. Keeping them simple helps facilitate easier maintenance and promotes reusability.

7. Handling Date fields in Test scenarios

Whenever we are handling the date fields, if the future or past dates are to be referenced then in that case it is advised to use dynamic data for such fields. Because in case we need to insert current date every time we are executing the Test Case, then the date passed through LDR will fail the Test case.

For such scenario we can create a generic reusable component and take out the past, present and future dates and set it in either the output parameters or the global variables. This way we can use date fields seamlessly in test cases.

8. Creating the LDR Vs Creating reusable component

Sometimes there are multiple data which needs to be changed frequently.

For example, consider credentials for logging in to the application,

There can be Role based users having different credentials. The username might change if a particular user’s access is reassigned or deleted. In that case we will have to change the user credentials on all places in LDRs wherever it is used.

In this case we can store the credentials in an Excel file and based on Role the creds are taken out and used as input for Username, Password fields

Here we will be giving a Role instead of username and password, and based on role the Username, Password will be fetched. In case the User credentials are changed we can simply modify the used Excel File and the changes will be reflected everywhere.