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, to test an ERP workflow to create and approve a product requisition, you can create four reusable components: one for logging in, another for creating a requisition, a third for approving requisition, 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. Create New test cases using reusable components containing parameterized steps
While creating a new test case, the first thing to consider is reusability of its steps. If 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.
But how exactly does parameterization of components help?
A reusable component could be mapped across several test cases for different workflows. For example, the login component for Oracle may be mapped to test cases of HCM and SCM modules. Now, the same user credentials may not work as test data for both modules. Thus, instead of mapping hardcoded user credentials in the login component, we pass Username and Password parameters in the component. Now, in different test cases, we can pass different user credentials to these parameters. In this way, we will be able to use our single component across different test cases.
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.
This action is taken 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 a few steps that are going to repeat in any additional 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 scenarios, 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 need to be changed frequently.
For example, consider credentials for logging in to the application,
There can be role based users with 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 credentials will be mapped and used as input for Username and 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.
9. What to use for creating test steps for reusable components - Recorders or Keywords
When creating test steps for ERP testing, it's best to use keywords instead of recorders. While recorders may capture test steps effectively, their steps may fail during execution after a period of time. This happens due to a change in underlying object properties' web elements on ERP application page. After the objects are changed, the test execution will give Object not found/Web element not found error. Using Bytext keywords helps in handling such dynamic web elements whose properties keeps change.
For instance, in Oracle ERP, the "Username" field on the login page might have varying technical properties, but its text label remains consistent. Using a keyword to locate the "Username" field by its text ensures that your test steps remain reliable even if underlying properties shift. This approach enhances the robustness of your tests, making them resilient to changes in Oracle ERP's dynamic elements.
If you follow the above practices, you will be able to create flawless reusable components. For more info on creating reusable components click here.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article