Maintaining a test automation framework with Appium for multiple operating systems can feel daunting at times. Have no fear! Quilmont has developed the perfect solution by leveraging the Page Object Model. The POM is the best way to separate data from test code while maintaining a single codebase for multiple operating systems. Through advanced programming logic we help organizations reduce time and effort spent by developing and maintaining test automation code with Appium across multiple operating systems.
POM is an object repository design pattern provided for Selenium Webdriver. POM is indisputably the best approach toward maintaining an Appium framework for a multitude of UI objects. The purpose of the POM is to provide a design pattern that when appropriately followed allows for quick and easy maintenance for any possible changes that may occur as various applications are updated and changed. When following the POM structure, there must be a corresponding page class created for each page that a particular application has. These corresponding page classes are used to identify and define the various objects on the application’s page, as well as any methods that may be used. The benefits that the POM provides are that it keeps the operations and flows of the UI separated from verification, which allows the code to stay more clean and easier to understand.
A Test Base is a page class which is created for passing the capabilities that are specific to the UI being tested. For example, contained within a Test Base for an Android device could be specific capabilities such as the platform name, device name, automation name, the app, app package, and app activity. Similarly contained within the same TestBase could be specific capabilities for iOS. The way that multiple capabilities for completely different UI’s can be contained within the same Test Base is through what is known as a switch statement. Switch statements allow for the different UI capabilities to stay separated from each other and divided up case by case. One case contains the required capabilities for Android, and then another separate one for iOS. Then, dependent on which device a user is trying to test at a particular period of time, a switch can be used which states that he/she is testing specifically on either an Android or iOS device at that specific time, causing only the capabilities set for the Android or iOS’ case to be called.
Each specific application page has an Application Page class created for it. Within these Application Page classes, UI objects from the pages that they represent are identified. Methods are also created within these page classes which are used to perform various actions on the page. Application Page classes can be divided up via specific UI’s such as Android or iOS, and then specific pages based off of those different UI’s.
In a separate package each Application Page class has a corresponding Application Page Test. These Test classes are created specifically to call the different methods to be performed, which were created within the Application Page classes in a logical order. Many times the same Application Page Test can be performed on an Application Page, despite the application being tested on a different UI such as iOS or Android.
Let’s say there’s an application that needs to have its Login Page tested for both Android and iOS. A properly maintained Appium framework would follow the POM, and have a corresponding class page created for the Login Page on the application for both Android and iOS. Each of these class pages contains all of the needed UI objects for their respective Login Page, along with all of the methods needed to be tested for it. The user first goes to his Test Base, and applies the switch statement to only use the capabilities provided for Android. He then goes down to his single application page test he created for this application’s Login Page and runs the test. He finds that some unique identifiers specific for the Android version of this application have been changed, and so he goes into the Login Page class for Android and fixes them. He then changes the switch statement over for iOS capabilities and runs the same application page test, but this time for the iOS specific class page and finds no errors. His job is complete.
Properly maintaining an Appium framework through the use of the POM, switch statements, and separated Application Pages and tests can prove to make UI automation much simpler. By using this approach, even the largest of projects can be more easily scalable and managed. In fact, this approach can even be used to run automation concurrently on top of hundreds of different devices through our partner tool’s AWS Device Farm.