What is Appium?
Appium is an open source testing tool used in test automation using web driver in native, mobile web and hybrid applications on iOS mobile, Android mobile and Windows desktop platforms. It provides multi-language support such as Java, Objective-C, JavaScript, Node.js, PHP, Python, Ruby, C#, Clojure, Perl.
It can be installed in one of two ways: via NPM or by downloading Appium Desktop, which is a desktop-based way to start the Appium server.
Appium supports “cross-platform” i.e. cross-platform test execution, which means tests are written for multiple platforms (iOS, Android and Windows) using the same API.
Running Appium on multiple devices simultaneously
Parallel testing is always necessary to reduce the need for human power and increase productivity. Appium also allows us to run our concurrent test suites. This feature aims to ensure maximum quality and reliability by running cases on multiple devices and various platforms.
The simultaneous operation of the executed cases on different platforms reduces the need for human power to a minimum and also saves a great deal of time.
Let’s say 10 devices are connected to your computer and when you type the command “adb devices” it will bring up all the devices connected to your PC.
To run Appium on multiple devices simultaneously, we need to run multiple Appium servers. This means that we need to set up a separate Appium server for each of our devices. Every instance of Appium server needs to be registered in the hub.
So, to run the test on ten different devices, you would be running ten different Appium nodes.
Such an application leads to high system memory consumption and also becomes more tedious when it is necessary to sync more devices.
Also, it is expensive and difficult to maintain, to buy any device available in the market and run your test on each one separately.
To meet this challenge, we can integrate existing Appium testing into the appropriate Device Farm. Through Device Farm, we have access to thousands of mobile devices and tablets available in a wide variety of operating system versions.
There are several such device groups on the market, as indicated below:
AWS Device Farm
Google Cloud Test Labs
Xamarin Test Cloud
Sauce Labs
Perfecto
By choosing one of these device groups and integrating into your project, we can work on devices from multiple different platforms. For the integration of these device groups into our project, the user documents on the official websites of the selected device group will be very useful.
So, what should we do if we do not have the opportunity to work with one of the device groups mentioned above? In such a case, we need to create our own device farm and integrate it into our project. First of all, what we need to do is to determine the most preferred devices and versions by the users. The closer it is to the user’s point of view, the greater the success and reliability of our project will be.
The next step after creating our device farm is to run tests on these devices in parallel. We can solve this part by integrating Selenium Grid into our project.
Then we can say that first of all, you need 2 vehicles and a mobile device to create our own device farm and integrate it into Appium.
These:
- Selenium Grid (http://www.seleniumhq.org/download/)
- Appium (http://github.com/appium/appium-desktop/releases/)
- Mobile devices
Selenium Grid allows you to scale tests by deploying them across several machines.
The Steps to Create a Mobile Device Lab are as follows:
1- Establishing a fully working Selenium Grid Infrastructure
2- Generating JSON file for Appium to manage our mobile devices
3- Running Appium Server for each device
4- Changing project structure
Establishing a Fully Working Selenium Grid Infrastructure
Selenium Grid (SG) comes in *.jar file and is run in console. There are some parameters you need to configure while running Selenium Grid.
The most basic ones are explained in the example below. By changing the “Port” parameter, you change the default port of the SG.
The role parameter is set as the “hub” parameter and acts as a central request collection point of the SG, taking all test requests and distributing them to the correct nodes.
“java -jar selenium-server-standalone-2.53.0.jar -port 4444 -role hub”
After starting the above command, you can see Selenium Grid is fully functional by pointing your browser to the URL http://localhost:4444/grid/console.
Generating JSON File for Appium to Manage Our Mobile Devices
In this step we need to create *.json files for each mobile device. These files have two parts.
The first section “Capabilities” holds certain information about mobile devices such as device IDs, browsers, OS names and OS versions.
The second part is “Configuration” and this part contains information about Selenium Hub .
Selenium Grid maps test requests to devices using the definitions in the Capabilities section.
After creating this file, save it as “node-devicename.json”.
You need to create a separate .json file for each mobile device.
Running Appium Server for Every Mobile Device
In this step, you need to configure the Appium Nodes. Appium can only manage one mobile device, so we need n Appium servers to interact with n devices.
First, we need to create a small batch file that triggers Appium.
This command should be executed in Appium’s folder.
You can see this command example below:
node.exe node_modules\appium\bin\appium.js <font></font>
–session-override <font></font>
–nodeconfig c:\selenium-server\node-samsung.json <font></font>
-p 4726 <font></font>
–bootstrap-port 2252 <font></font>
–udid 021YHB1039986676
Changing Project Structure for Mobile Device Lab
This section is based on a project I developed using Java and TestNG.
Modifying the TestNG.xml File
At first, you need to modify your testNG.xml file.
You can manage your test suites with this .xml file.
You should duplicate your test tag for each device you have.
In this way, you will pass different parameters to your RemoteWebDriver and run your tests on a specific device.
To fully automate your process, I recommend using a Continuous Integration tool to trigger test runs.