A common problem among testers is that the descriptions for the same object for your iOS and Android apps are different. So how do you handle these differences in your automated Appium tests? Here's how to use the same script across all platforms for testing.

Last month, we wrote a blog detailing how you can use a single script for mobile testing across all platforms. I wanted to revisit this topic given that the mobile testing landscape has changed since our original post. While all the information we shared is still true for our Mobile Labs Trust™ plugin for HP-UFT, many new test automation tools have since been released and are gaining traction in the marketplace. Today, the tool getting the most industry buzz is Appium.

At its core, Appium relies upon drivers for interfacing with various platforms. The drivers for iOS and Android translate the script automation calls on the Appium Server into the native automation technologies provided by Apple and Google. But, a common problem among testers is that the descriptions for the same object for your iOS and Android apps are different. So how do you handle these differences in your Appium tests?

This is where the PageFactory, provided within the Appium Client Library, can be used to make your object identification easier. Much like the common data model we discussed in our blog for Mobile Labs Trust, the PageFactory allows you to abstract the object identification into a page object model that allows for cross platform scripting. Basically, you create an object representing each screen of your application and within each screen, you identify all the individual objects for each platform. The benefit of abstracting the object information in this manner is that your test methods are not responsible for object identification. Your test methods are only responsible for the pass-fail state of the object within its screen.

It is recommended that within your code you separate the object identification and test classes.

In the example below, you can create an abstract class for your entire application. For this abstract class, you need to perform the following method to enable the PageFactory:

PageFactory.initElements(new AppiumFieldDecorator(driver), this);

Doing this allows you to set up annotations to use a single element to find an object on both iOS and Android.

Separating classes for each screen allows you to simply organize your object identification easier and to write methods that may be needed for that screen.

In the picture below, the objects for the application login screen have been moved into their own class called LoginScreen.

As you can see, for the LoginScreen class, you can use different ways to identify objects within the application. Notice how they can have different properties, but when used by the test, they represent the same object. This is because we create the public MobileElement object with its own unique name. This is the name that will be used in the test.

Now when we want to write a test case, we can do so using instances of our screen classes. Not only does it keep the object identification method out of the script, but it makes it much easier to read the test step. LoginScreen.usernameField is much easier to read within the script than including the object descriptor in the command. Plus, you only need the one command for both platforms, iOS and Android.

The login test below shows you that the test steps are not responsible for object identification. Should the objects change, we simply need to update our screen class and object properties.

This makes maintenance of the scripts much easier. By having to change the object identification method in just one location, there is no need to update any other script that is using that object.

But, once the test script is written that supports both iOS and Android, how can you execute on real devices? To alleviate the need to construct your own Appium Server Farm with all of the devices connected via USB cables, Mobile Labs’ deviceConnect™ has an Appium server built in, so running your mobile web and native applications using Appium has never been easier. All you must do is point your driver creation statement to the deviceConnect Appium Server and you are off and running.

Mobile Labs’ Appium support offers high levels of performance and enhanced reliability. Through the built-in Appium support offered with deviceConnect, mobility teams can get Appium up and running faster than ever before by avoiding the time-consuming and costly tasks of buying, building and configuring individual Appium servers in-house.

Have questions about deviceConnect? Learn more about this private device cloud, available as both an on-premises and as a hosted solution by viewing our video demo.

Steve Orlando

Steve Orlando is a seasoned development and quality assurance professional with experience testing and developing mobile, Web, mainframe, CRM and desktop applications. In his role as director of product development for Mobile Labs, Steve drives the design and implementation of the company’s private mobile device cloud, deviceConnect™ as well as its automated mobile app testing solution, Mobile Labs Trust™.

More Posts | Website