Using Page object model and Page Factory with TestProject
Test automation is an important part of any software testing project, but effective test automation needs to be thought through and designed well. There are several strategies and methods that can be used to keep your test automation efficient and easy to run and maintain over time. A couple of common strategies for this include the page object and page factory models. These approaches to test automation allow you keep the tests modular and well organized for maximum effectiveness. These strategies are most often used in coded tests and TestProject supports them in any coded tests you make or run in the platform, but the same concepts can also be used within the Test Recorder as well.
Page Object in Recorded Tests
The page object model is essentially a way of organizing your tests so that you have one class per page and that class contains the elements for that page along with the methods for acting on those elements. A similar concept can be applied within the test recorder. For example, you could create a test for logging into your app. You can then use that test in all other tests in the project that need to start with logging in.
To do that in the test recorder, just add a new test and change the type to Test.
Add a test and change the type
Set the type to Test
You can then chose the login test as test step in your current test case.
This let's you re-use the same login test in multiple tests which means that if something changes on the login page, you only need to update that one test and all tests using it will get that change.
Page Object in Coded Tests
The Page object model is of course well suited to coded tests. This section will walk you through an example of how you can use the page object model in an android testwritten in Java.
Build your First Test with Appium
Let’s start by learning how to create a “plain” Appium automated test for Android. The code below automates the TestProject Demo app. You can download its APK or view the complete source code.
To start the automation, the test prepares Android driver capabilities with all the required information about the device under test (DUT) and App under test (AUT). Then, using these capabilities, it initiates the Android driver that will be used to invoke various Appium actions on the mobile application. To perform the actions, Appium must identify the elements it interacts with. To do so, it uses various location strategies.
The most convenient location strategy is the ID (aka. resource-id in Android). For example, it searches for the login button to make sure that the login screen is displayed using By.id and the value login. I will show how to identify your element locators later in this tutorial, here.
Page Object Model and Page Factory Advantages vs. “Plain” Appium
This demonstrates how to create a “Plain” Appium test, but let's see how we can improve it with the Page Object Model (POM). Below are the advantages of utilizing POM as opposed to “plain” Appium:
Mix of test logic and UI actions
Separation of duties to OOP classes
Decoupling objects library from decision taking in tests
One authority to manage page elements and UI action
No duplicate findElement calls and UI manipulations
Self-explanatory code, thanks to FindBy annotations
Create Page Classes by Utilizing Page Object and Page Factory
In order to create the page object model you will need to define the page classes. In the demo application there are two pages: the Login page and the Profile page.
To map the elements, POM uses the FindBy annotations. These annotations should be used to decorate the fields declared for the elements. Location strategies can be different, but the most convenient one is the ID (aka. resource-id in Android).
While creating tests like this it can be helpful to use the inspector and element locator in order to find the correct values.
These values can then be placed in the annotations in the code. Then, initElements method residing on the PageObject factory class should be invoked to initialize all the elements of the page.
Elements, page class fields, are now being used across the page to manipulate the UI and encapsulated in methods invoked externally.