A common problem among testers is that the same object for your iOS and Android apps have different scripting. So how can enterprise mobility teams handle these differences in automated Appium tests? Here's how to use the same script across all platforms for testing.
Last month, we wrote a blog detailing how testers can use a single script for mobile testing across all platforms. We 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.
As good testers know, a solid automation framework is one of the most basic ways to ensure your app deployment goes smoothly and we're happy to have Appium integrated with deviceConnect. 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 testers and quality assurance teams handle these differences in Appium tests?
This is where the PageFactory, provided within the Appium Client Library, can be used to make object identification easier. Much like the common data model we discussed in our blog for Mobile Labs Trust, the PageFactory allows users to abstract the object identification into a page object model that allows for cross platform scripting. Basically, users create an object representing each screen of an application and within each screen, users must identify all the individual objects for each platform. The benefit of abstracting the object information in this manner is that test methods are not responsible for object identification. Test methods are only responsible for the pass-fail state of the object within its screen.
It is recommended that within the code users should separate the object identification and test classes.
In the example below, we've provided automation testing scripts so enterprise mobility teams can create an abstract class for an entire application. For this abstract class, testers need to perform the following method to enable the PageFactory:
PageFactory.initElements(new AppiumFieldDecorator(driver), this);
Doing this allows testers to set up annotations to use a single element to find an object on both iOS and Android.
Separating classes for each screen enables testers to simply organize object identification 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 the example above shows, for the LoginScreen class, it is possible to 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, only one command is needed for both platforms, iOS and Android.
The login test below shows 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 testers execute on real devices? To alleviate the need to construct an Appium Server Farm with all of the devices connected via USB cables, Mobile Labs’ deviceConnect™ has an Appium server built in, so running mobile web and native applications using Appium has never been easier. All enterprise mobility teams must do is point the driver creation statement to the deviceConnect Appium Server to get started.
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.
For customers who are currently using deviceConnect, Mobile Labs' GitHub profile is a valuable resource. Currently, we have an example of an Appium cross-platform script that testers and quality assurance teams can use to run Appium tests. Why not give it a try?
# The deviceConnect server URL # i.e. http://192.0.2.0/Appium deviceconnect.url= # Your full username # i.e. firstname.lastname@example.org deviceconnect.username= # Your full api token # i.e. 00000000-0000-0000-0000-000000000000 deviceconnect.api.key= # A comma separated list of one or more iOS device ids # i.e. 0123456789012345678901234567890123456789 or # 0123456789012345678901234567890123456789,0123456789012345678901234567890123456789 ios.ids= # The bundleId for your iOS application # i.e. sample.company.App ios.bundle.id= # A comma separated list of one or more Android device ids # i.e. 0123456789012 or 0123456789012,0123456789012 android.ids= # The bundleId, and Activity, for your Android application # i.e. sample.company.App/SampleActivity android.bundle.id=
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.