Hi all, In this article I am going to explain how to create a basic mobile device lab (a.k.a device farm) for your mobile automation projects.

First of all, you need 2 tools and mobile devices:

Grid allows you to scale by distributing tests on several machines (parallel execution). You will also run one Appium node for each mobile device that you will connect to your device lab. At the end, you will have an infrastructure as below.

device farm

Steps to Create a Mobile Device Lab are as follows:

1- Setting up a full running Selenium Grid Infrastructure

2- Creating JSON file for Appium to manage our mobile devices

3- Running Appium Server for each device

4- Changing project structure

Setting up a Fully Running Selenium Grid Infrastructure

Selenium Grid (SG) comes in a *.jar file and it runs on the console. There are some parameters that you need to configure while running the Selenium Grid. The most basic ones explained in the example. By changing the “Port” parameter, you modify the default port of SG. Role parameter is set as “hub” parameter, and it defines that SG behaves as a central request collection point and it receives all the test requests and distributes them the right nodes.

java -jar selenium-server-standalone-2.53.0.jar -port 4444 -role hub

After initializationof above command, point your browser to http://localhost:4444/grid/console URL and see that Selenium Grid is fully functional.

Creating JSON File for Appium to Manage our Mobile Devices

In this step, we need to create *.json files for each mobile devices. Those files have two parts. The first part is “Capabilities” and it keeps specific information of mobile devices like their device ids, browsers, OS names and OS versions. The second part is “Configuration,” and it comprises of information about the Selenium Hub.

Selenium Grid matches test requests with the devices by using definitions in capabilities part. In below at JSON file’s capabilities part, three parameters hold crucial information of the device.

The other parameters are host, port, URL, hubPort, hubHost and you can also change them at Configuration part. You need to modify them according to your infrastructure. Host and port are host IP and port of your Appium server.

After creating this file, save it as “node-devicename.json”. For each mobile device, you need to create a specific file by changing the parameters that I explained above.

To get your device’s UDID, you need to turn on “Developer Settings” on your mobile device and runadb devices” command on the console. Turning on the “Developer Settings” of a mobile device is varying. Thus, you need to find how to do this for your devices in Google 😉

Running Appium Server for Each Mobile Device

In this step, we will configure Appium Nodes. Appium can only handle one mobile device, so we need several Appium servers to interact with all devices as shown in the first picture. Thus, we need to create a small batch file which triggers Appium. This command must be executed in Appium’s folder. That command is shown below:

As you can see, there are many parameters that we need to send Appium server. NodeConfig parameter points the path to the JSON file. “P” and “Bootstrap-port” parameters override the default ports that Appium runs. “UDID” is the device id that Appium will interact.

When you run that command, point your browser to Selenium Grid landing page(http://localhost:4444/grid/console). You will see Appium servers are running properly.

device lab

Changing Project Structure

This part is based on a project that I developed by using Java and TestNG. The below configuration is for that project.

Changing TestNG.xml File

At first, you need to modify your testNG.xml file. You can manage your test suites with this .xml file. For every device you have, you’ll replicate your test tag. In this way, you will pass different parameters to your RemoteWebDriver and to run your tests on a specific device.

You need to set “Thread-count” parameter to your total device number in your device lab.

Changing Java Code

In automation code, we get parameters from our TestNG.xml file and pass them to the Android, iOS, Remote driver. Thus, we need to add “@Parameter” annotation above our test methods, and we can use them in those test methods. In this way, we can use those parameters in DesiredCapabilities Object.

To fully automate your process, I suggest you to use a Continuous Integration tool to trigger test runs. I used Maven as a build manager.

At last, everything is configured and ready to run, hit “Run” button on Jenkins (CI tool) and see all your devices will run the same test in parallel. Automate this process in parallel makes us a happy tester 🙂

If you execute more than one thread for your parallel test runs, please avoid using Singleton Design Pattern in your PageObjects. This implementation causes some weird behavior during test execution. It is better to use ThreadLocal structure so RemoteWebDriver object becomes thread-safe.

You can download my demo project on https://github.com/canb0/MobileDeviceLab

Video Link: https://vimeo.com/183266547



Since 2005, Keytorc Software Testing Services has been assisting its customers to manage their critical software testing processes to reduce the total cost of producing high quality systems. Keytorc uses a risk-based prioritization approach to get to the right answers and overcome the top reasons for failure.The Company has the best references from the banking, insurance, telecommunications, IT, commerce and public sectors.