Custom Function page
Last updated
Last updated
The Custom Function page is designed for creating reusable functions for the application. Generally, reusable functions are consumed by test script pages.
Custom page functions can be accessed through the navigation path Automation > UI Testing > Custom Page Function.
For any automation, maintenance is a key factor, and it can be reduced by multiple factors, with one of them being reusable functions. For example, consider a login scenario used by all test scripts. By creating a common flow for the login function, which can be consumed at the test script level, any future changes or additions to the login flow only require updating the reusable function, thereby minimizing maintenance efforts.
Similarly, in the case of 10 test scripts for a Payment page, where the common element is the predependent page leading to the Payment page, creating a reusable page function for navigating to the Payment page can be beneficial. This approach allows for updating the flow in one method, reducing maintenance work across all relevant test scripts.
If multiple test scripts share a common flow in the application, please create a reusable page/function for that shared flow.
QAautoMATER provides three sections on the Custom Page Function page:
Custom Page/Function Name
Add Reusable Test Step
Debug Section
This section is used for providing the name of the page and a custom section. Here, you can find a "Reusable" listbox that includes options for both "Page" and "Function" values. If you want to create a shared flow for the entire application that can be used across all pages, select "Function." However, if you are trying to create a common flow specifically for reaching a particular page, then select "Page."
For functions, do not provide any spaces. For page names, use self-descriptive and concise terms, such as "User is on Payment Page."
When multiple teams are working, it is possible to create duplicate functions for the same objective. To set a protocol for writing function names, we suggest using the prefix as "Page_" and then the user's underscore, for example, "LoginPage_LoginToApplication" or "PaymentPage_FillPaymentTypeForm."
ADD REUSABLE TEST STEPS is a table section where common flows or test steps can be added by clicking on the 'Add Row' button."
This table contains three buttons:
1. Add Step, 2. Delete Step, and 3. Utility Data.
The 'Add Step' button is used to add a new test step to the table
The 'Delete Step' button is used for deleting the selected test step.
The 'Utility Data' button is used to provide random data in a test step
The 'Debug Custom Function' is used for debugging the custom function step.
The 'Debug' section has four subsections: Environment, Application URL, Screen, and Device/Browser. All these values are retrieved from the configuration page settings; however, the URL can be updated directly from this section.
Upon clicking the Debugger window, the provided Application URL will be launched on the selected browser; this is a precondition for debugging the test step
For debugging a test step in the common flow, first, select the test step radio button and click the 'Debug Step' button. In the debugger window, you can view the result of the test step.
Debug Page function is used to debug the page-level function, which can be viewed in the 'Select Predependent Page' section
Please note: When debugging all the steps, always close the debugger window using the cross icon. It is a mandatory step
Reusable Type - Function
For a Sauce Demo application, there is a login screen. After proceeding through the login, there is a product page where an 'Add to Cart' button is displayed next to each product name.
So, in this scenario, the login process consumes all test scripts, and the 'Add to Cart' functionality can be reused after selecting the product for the next page. In this context, we will create two functions:
1. LoginPage_LoginToSwagLabApplication
2. ProductPage_AddProductOnCart
LoginPage_LoginToSwagLabApplication
Select the reusable type as 'Function,' provide the suggested function name, and click on the 'Add Step' button.
In the step description, we need to provide a description for each step. For the login scenario, in the first step, we will provide 'Enter Username,' in the second step 'Enter Password,' and in the third step 'Click on the Login button.
After providing the step description, the action and web element will be automatically created. Now, we need to ensure that the test step is working fine by using the debug feature.
Recommendation: For generating actions and web elements, the step description should be shorter and generic. If an object has more words, write it in single quotes. For example, 'Click on 'Add to Cart' button.'
For the step definition 'Enter Username,' you will get the details given below:
To ensure the step is working fine, first, click on the Debugger window, select this step, and click on 'Debug Step.' Then, you will see the result
Please note: In case the action and web element are not generated, or if the debug action fails, select the action for the web action dialog. You will get a dialog window after clicking the action cell of the test step. Similarly, for the creation and updating of the web element, click on the web element cell from the test step and update the property from the dialog.
So now, for 'Enter Username,' we need to parameterize the username. To parameterize the value, we use ARGS.KeyName. For example, for the Username, we need to provide ARGS.Username in the 'Value to be sent' section under the value column.
Now, we can perform similar actions for 'Enter Password' and 'Click on the Login button
Now, click on the 'Save' button. The custom function will be saved on the server, and on the test script page, we can directly consume it.
If you want to use a custom function in the test script, first click on the action name. Only after selecting the action, provide the step description
Custom functions can be viewed under the 'Application Method' section. You can also see the details, arguments, etc., by expanding this from the web action dialog window.
After selecting the radio button for this method, it will be displayed in the action column of the test step table.
Now you can add the step definition and provide the username and password for the selected method.
ProductPage_AddProductOnCart
The objective of this function is to click on the 'Add to Cart' button based on the product name. There are multiple ways to achieve this, for example, searching. However, the best way is to create an XPath for 'Add to Cart' based on the product name. If we can create the XPath in that way, then we can parameterize the XPath and achieve the solution in O(1) complexity.
For the XPath //*[text()='Sauce Labs Bolt T-Shirt']/../../..//button[contains(@id,'add-to-cart')], it is pointing to the 'Add to Cart' button. This XPath also allows us to provide the product name.
In the step definition, we have added the step as 'Click on 'Add to Cart' button for the provided Product,' then the action and web element are automatically generated.
In our case, we need to parameterize the web element property so that the product name can be passed. If we write the XPath as //*[text()='+ARGS.ProductName+']/../../..//button[contains(@id,'add-to-cart')], for updating the web element, click on the web element cell, and from the 'Add or Select Existing Element' dialog, update the XPath.
Once we add this locator property, the parameter will be generated in the value section
For parametrizing the value, provide ARGS.ProductName in the 'ProvideArgsValue,' then update the value and save the function
On the test script page, after selecting this method, we can provide the parameter as the product name
Handle shadow element
If any web element is present inside a shadow root, we need to pass the shadowRoot key as an array object. The array object should contain the shadow DOM root properties. For example:
Here, DOMSIGNUP is an object that comes from the object repository page.
If a web element is present in a nested shadow DOM, we can pass the values in sequential order in the shadowRoot key
Video file for creating custom function (LoginPage_LoginToSwagLabApplication)
Video file for creating custom function (ProductPage_AddProductOnCart)
Reusable Type - Page
In the Swag Lab application, after the login page, we encounter the product page. The product page has X number of test cases associated with it. Following the product page, we reach the shopping cart page, where Y test scripts are applicable. In order to streamline our testing process, we will create two page functions:
User is on the Product Page - ensuring that X test scripts utilize this page function.
User is on the Shopping Cart Page - allowing Y test scripts to share the same page
User is on the Product Page
When creating the page function for 'User is on the Product Page,' since we already have a custom function for logging into the application, we can directly incorporate it into the page-level function to navigate to the Product Page
After saving this page function, we can directly call it in the test script's Page function section
User is on the Shopping Cart Page
When creating the page function 'User is on the Shopping Cart Page,' we leverage the existing page function for reaching the product page. Within this page function, we consume the previously created page function. Subsequently, we utilize a custom function designed for selecting the product. Again, we make a function call to this custom function, and finally, proceed to click on the Shopping Cart icon to navigate to the cart page.
After saving the page function, you can view it on the test script page under the 'Page Function' section.
Video file for creating page function (User is on the Product Page)
Video file for creating page function (User is on the Shopping cart Page)