Presence of same application in multiple mobile platforms (iOS, Android etc) is quite common as application developers want to capture the market of all popular platforms. Automating your app for multiple platforms is challenging when they are native applications. Apps on different platforms differ with element definitions, element hierarchy, page hierarchy, and even workflows. One solution to this problem is, to maintain different automation code bases for different platforms or to automate them in respective automation technologies. If functionality and workflow of the app in different platforms is same, then only changing parameter is object definition. How do we handle this scenario with page object pattern?
Page Object Pattern is popular approach followed by automation developers to definite separate classes for each functional page to definite elements, actions, and validations. In basic page object implementation, a typical page class include element definitions, getting values from controls, setting values to controls, actions (like click, check, select) on controls, and validations (or assertions).
To address multi platform apps with common automation code base, we can reorganize the page object classes in such a way we can create workflow classes with methods to a particular part of functionality and contains calls to methods in one or more page classes. This way it moduralizes the frequently called actions into workflow methods. Using this approach, tests look more readable, and code re-use is improved. When there is a change in functionality, this approach reduces the maintenance of scripts that we don't have to make changes in multiple scripts, changes are needed in workflow methods.
In this approach, we create separate ObjectMap classes which contains object/element definitions for different platforms. Element definitions can be maintained in the class itself or can be loaded from a properties file. Constructor of ObjectMap class contains parameter to determine the mobile platform. Based on mobile platform, element methods returns the proper element object. Page object contains the action methods, element getter/setter methods for values like reading text from textbox or setting a value to textbox.
Scenario: Let's try this approach with an example. In a ToDo app, one of the tests is to create a task after logging into the system, and verifying whether task is created. This test involves 3 steps, 1. Login to system, 2. Create a task, 3. Check. Creating a task involves entering basic details of a task, assigning resources (resources are added from a different page), and saving the task. Create task method involves accessing methods from Create Task page and methods from Resources page. We can create a workflow method called CreateTask in TaskWorkflow class which calls page methods from create task page and resources page. This way if there is any change in create task workflow in future, we can make change in CreateTask workflow method.
Page Object Pattern is popular approach followed by automation developers to definite separate classes for each functional page to definite elements, actions, and validations. In basic page object implementation, a typical page class include element definitions, getting values from controls, setting values to controls, actions (like click, check, select) on controls, and validations (or assertions).
To address multi platform apps with common automation code base, we can reorganize the page object classes in such a way we can create workflow classes with methods to a particular part of functionality and contains calls to methods in one or more page classes. This way it moduralizes the frequently called actions into workflow methods. Using this approach, tests look more readable, and code re-use is improved. When there is a change in functionality, this approach reduces the maintenance of scripts that we don't have to make changes in multiple scripts, changes are needed in workflow methods.
In this approach, we create separate ObjectMap classes which contains object/element definitions for different platforms. Element definitions can be maintained in the class itself or can be loaded from a properties file. Constructor of ObjectMap class contains parameter to determine the mobile platform. Based on mobile platform, element methods returns the proper element object. Page object contains the action methods, element getter/setter methods for values like reading text from textbox or setting a value to textbox.
Scenario: Let's try this approach with an example. In a ToDo app, one of the tests is to create a task after logging into the system, and verifying whether task is created. This test involves 3 steps, 1. Login to system, 2. Create a task, 3. Check. Creating a task involves entering basic details of a task, assigning resources (resources are added from a different page), and saving the task. Create task method involves accessing methods from Create Task page and methods from Resources page. We can create a workflow method called CreateTask in TaskWorkflow class which calls page methods from create task page and resources page. This way if there is any change in create task workflow in future, we can make change in CreateTask workflow method.
