Localization Testing with Appium Grid

harshit jhureley
3 min readMay 4, 2018

--

The world is getting smaller for mobile applications these days. A single mobile app can offers different services according to targeted geographic region. A plain native language is not just sufficient for the users. Different Culture and behavior are also embedded into these applications in form of localization and Internationalization to cover global market.

Hence the functional and behavior testing on each localized version of app are demanded and expected from automation testing. Furthermore, if the execution environment supports grid then the automation code should robust enough to distribute functional tests on the devices according to different culture. Basically, we are going to implement the code in such a way that it allows multilingual parallel test execution on devices with different cultural test data.

So, to fulfill our app dependency wordpress.apk can be used as test application. It supports several languages and the locator text and content-desc changes according to the device locale (language).

In this application, some locators such as id and class are constants with respect to languages. But we are going to use text and description (content-desc) identified through uiautomator to mimic the situation where locator changes with the locale and how to deal these changes in appium page factory pattern.

If you have faced the circumstances where certain element locator of any app are not consistent with respect to app language then maybe you have handle it by annotate a single element with multiple properties.

@AndroidFindAll({
@AndroidFindBy(LocatorForEnglish),@AndroidFindBy(LocatorForFrench)})
private MobileElement username;

But this solution only sounds good for those apps that support not more than three languages. What if language coverage in the automation suite is more than 8 languages? Now this makes the process of finding element and interaction slow with respect to each language.

At this point only one thing pop up in the mind is to modify the default structure of page factory pattern with something that select Page Object based on language. By this I do not have to alter page factory design pattern and still able to do the best usage of annotations.

So, In order to handle the page object dynamically based on language we just need to follow these 6 steps.

  1. A Common Interface is needed to handle mobile element of different languages. All we need is to create getter methods declaration for all the Mobile elements.

For instance, we create an AppLoginInterface to handle common UI elements which we are going to declare in different Login Pages (i.e. LoginPage_English, LoginPage_French).

2. Now we created multiple Login classes specific to each Language and Implement this common interface with them.

LoginPage_Eng

LoginPage_French

In these classes we defined the unimplemented methods of the common interface. The purpose of doing this is to dynamically control these language specific mobile elements through the common interface methods.

3. Now we need to create a base page where we can perform all the actions on these common elements.

The constructor of this class accepts the object of any of the class that implements this common interface. (AppLoginInterface)

4. Also, we will create a screen handling class which creates Page Objects based on passed language. And it provides the control mechanism to navigate to any screen at any step in our test classes.

5. Below is the testNG class which is going to be executed. We pass locale as a parameter in the configuration method. And page.initScreen(locale) will set the language for each device. Also you have to create a Driver class which create driver object based on capabilities parameter.

6. Now the final step is the structure of our TestNG xml and its execution.

GitSource:

--

--