An Alternative For Parallel Execution Using Appium Latest Version And TestNG For Mobile Testing

The mobile devices together with the applications brought a series of facilities for its users. In the Appium latest version, we have access to a powerful computer in our hands and it is up to us to make the most of it. However, who works to develop these mobile testing applications?

The developers who do this face some obstacles during the journey of conception, development, and delivery of applications. Words like multiplatform, platform, model, version, hybrid, native, etc., have become commonplace in the mobile world and we need to think of strategies to deal with them efficiently.

Test Parallelism

The concept of test parallelism helps us to face some obstacles, but we need to understand what it is about. Parallelism is about the ability to run two or more competing tests in different conditions such as Platforms, Models, Operating Systems, Versions, etc. It is possible to adopt the strategy of executing the same test under n conditions as there is also the possibility of running different tests under n conditions. This will depend on your objective: For the first case, check the portability of the same scenario between platforms, models, operating systems. And in the second case, give flow to the tests and decrease the execution time.

Solution for Parallel Execution Using Appium Latest Version

Whoever works with mobile development, during the development of their automated scripts, must have come across architecture to support parallelism similar to the image below:

1. Alternative for Parallel Execution
2. Selenium GRID

As a client, we have Java technology, TestNG as a testing framework, and java-client as the client implementation required to communicate with the Appium Server. The Selenium Grid, which allows orchestrating the execution of tests in parallel, works as a hub. Being necessary to perform a configuration of “nodes” that in the mobile context, will be the instances of Appium Servers and devices capable of executing the tests.

It is possible to perceive, in this architecture, some important points of attention:

1. To run on each device, it is necessary to configure a “node” with an instance of the Appium Server, requiring greater hardware capacity to support all these APIs and also making maintenance difficult.
2. We can add the Selenium Grid service to the project architecture, as it is responsible for orchestrating the executions including another layer of abstraction, and also increases the complexity of maintaining the project.
3. It is necessary to create configuration files responsible for making Selenium Grid services available that subsequently register each node in the hub, making the project’s scalability difficult.
4. This architecture is functional, but we need to take into account the points raised above when defining our mobile testing automation strategy. Other alternatives can be analyzed and if they are likely to solve our problem, we can choose them too.

Also Read: Appium Mobile Testing

A Different Approach

The Appium version 1.7.0 brought a simple way to work with multiple simultaneous sessions during the execution of tests. We can use it in conjunction with TestNG as an alternative for running in parallel.

Alternative For Parallel Execution

As a client, we have Java, TestNG, and java-client.

The TestNG together with the java-client allows you to create a structure. That is capable of starting more than one session in a single instance of an Appium Server.

The following settings become necessary:

name = ”Smoke Tests”, is the name given to the test suite. Generally representing the type of execution, functionality, or a group of functionalities.

parallel = ”tests” , tells TestNG that execution is parallel for all methods that are in the < test > tag .

thread-count = ”3”, specifies the number of threads that can be allocated for execution. Remember that all the methods of a < test > tag are executed on one thread, but each < test > tag will be on a separate thread.

name = ”Google Pixel 2 – 8.0″, name of the execution for the < test > tag, in this case, it is representing that the executions of this tag are on a Google device.

name = ”deviceName” value = ”Google Pixel 2–8.0″, name of the device that will be registered in the Appium session. (mandatory parameter)

name = ”used” value = ”192.168.243.101:5555”, unique id information for the device on which the test (s) will be run. We can obtain through the ADB devices command, in the case of Android or idevice_id – list, in the case of iOS.

name = ”system port” value = ”8200”, a key parameter for registering multiple sessions in a single Appium Server instance. In the case of Android, this parameter is the system port and in the case of iOS, it is the wdaPort.

These parameters inform through the .xml that includes the test suite we pass through the TestBase. To the class responsible for assembling the object of the Appium session.

Alternative for Parallel Execution

The Appium session is set up based on the parameters that pass directing the client’s calls to Appium Server localhost on port 4723. The same dynamic is performed for the other executions, just inform the execution parameters in the < test > tags in the .xml file and allocate the number of threads needed for execution.

TestNG .xml

Once we complete this, the Appium Server is responsible for orchestrating all sessions sent by the client so it is possible to run the tests in parallel. It is possible to enhance this execution architecture in parallel. This can create a local farm with a powered USB hub for the devices, using a Mac Mini with all the necessary tools for mobile testing.

That is configured to run on iOS, creating a network dedicated to the devices connected to the farm, to avoid internet connection problems. The idea is to bring one more alternative for the creation of your mobile testing architecture. There is space for discussion and to think about the ideal solution to our problem. The code for this example is available on this project on Github. If there are any questions you have, feel free to address them in the comments section below.

Also Read: Steps For Testing Mobile Apps Using Appium With Cerberus Testing