Client-Side vs. Server-Side Execution for Mobile Test Automation

Client-Side vs. Server-Side Appium

One of the requirements of using Appium for mobile test automation is to start the Appium server in the background so that it can listen to the requests from the mobile app under test. And there are multiple ways that we can install and start the Appium server in the background.

While running Appium tests from a local machine, we have to launch the Appium server on a specific port and update the desired capabilities to point the server running locally. But there should be a better way to handle these and avoid extra work on desired capabilities. Fortunately, Bitbar provides the ways to run Appium server client side as well as server side. In this post, we will compare the client side and server side Appium and see both sides of the coin.

Client-Side vs. Server-Side Appium

With Client-side Appium, we need to configure Bitbar specific desired capabilities in order to execute the test on the Bitbar real device cloud from the local machine. However, the Appium server and the real devices are hosted in the cloud. You can read more about the client side Appium here. In the case of the server side Appium, we have to upload our Appium tests and we don’t need to configure the desired capabilities. In the server side Appium we will get parallel testing and device selection from the device group. This is the diagram showing the key difference between Client Side and Server Side Appium.

How client-side and server-side appium work

There is a great slide share document explaining the difference between the client side and server side Appium here.

Pros of Client-Side Appium

Either way of Appium execution will anyway achieve your end goal to verify your defined test steps. Let’s first see some pros of Client-Side Appium.

Local & Cloud Execution

One of the key benefits of Appium Client-Side Execution is the ability to launch the tests from developers’ local machine. This will allow quick testing of new features that are under development straight from the developers’ machine. We can trigger Appium tests on real devices by updating the Appium server address from local machine to the Bitbar Cloud hub. This will allows us to trigger the test run from any machine.

Ability to Configure the Devices of Choice

With Client-Side Appium, developers and testers are able to configure the devices of their own choice as client-side execution enables us to configure the desired capabilities and devices from the code.

Upload Local Test Results onto the Cloud

With Client-Side Appium, once the execution of test suites is finished, you can get access to the video recording of the test directly from Bitbar Cloud. Additionally,  you can upload .xml files to Bitbar Cloud and view test steps in a more readable way.

Cons of Client-Side Appium

In a way, Client-Side Appium is not bad to help teams get started with Appium test automation at the early stage. However, there are a few critical drawbacks of Client-Side Appium that might be overlooked and may have a huge negative impact on business success.

Flaky Tests

Client-Side Appium allows developers to start the Appium server from their local machines so test scripts need to establish the connection between the local Appium and the devices. As the tests are so dependent on the network connection with the local machine, they can become very flaky. The flaky tests cause loss of trust and waste of developer time in the investigation if the failure occurs because of the network or the test itself. 

Slow Tests

While using Client-Side Appium, there must be a connection between the local machine and the devices in the cloud. All the test files need to be transferred over the internet to the target devices for test execution, and when the tests are finished, the test results will be also sent back to the local machine through HTTP. This is really not the agile approach as the transfer of test files and results is dependent on the speed of the internet.

When the internet speed suffers, the whole team might be just waiting for the test results without being able to get instant feedback. The slowness in general affects the team productivity and waste of time.

Extra Work on Desired Capabilities

Desired capabilities are a set of keys and values sent to the Appium server and inform the server about the configuration of the automation session. When running Appium tests on the client side, you will need to configure those desired capabilities so that the test is ready for execution on Bitbar Cloud.

When you want to execute the Appium test on a specific device on the cloud or change target device from Android to iOS, you’ll need to edit some desired capabilities in order to get tests successfully executed every single time.

No Parallelism – One Device at a Time

Due to the nature of Client-Side Appium, here comes one of the biggest disadvantages – executing tests on only one device at a time, unless you have the luxury of having multiple terminals/VMs for parallel connections to the devices in the cloud.

It might sound ok if you run Appium tests to only verify whether the new test works on any single device, but it’s certainly counterproductive when you want to run these tests on a large number of real devices with Client-Side Appium.

Pros of Server-Side Appium

As the default approach of test execution, though Client-Side Appium does have its merits, the drawbacks are quite significant. And there’s a much better way, Server-Side Appium.

Zero Configuration

Unlike Client-Side Appium with which we have to constantly configure desired capabilities of target devices to enable test execution, there is no need for that when using Server-Side Appium. Once your test script is ready, simply select the devices you want to run your tests on Bitbar Cloud. The rest is taken care of by our platform. This reduces the hassle of configurations and potential errors in the configuration.

Parallel Testing

With the Server-Side Appium, we can execute tests on hundreds of real devices in parallelat the same time. All the configurations that are needed to run parallel tests will be handled by Bitbar Cloud under the hood. Appium servers get started under the hood and attached to selected target devices for parallel execution.

Faster & Stable Tests

As stated above, one of the main causes of flaky tests with Client-Side Appium is that all the test files and results would need to go through multiple layers of the network. That’s not the case for Server-Side Appium, as all the test files are uploaded to Bitbar Cloud first and test execution happens on the server. It’s considerably faster than the Client-Side execution approach to get more reliable test results. 

Monitoring

With Server-Side Appium, the monitoring of the tests become so painless as we can see test execution in real time and test results in terms of screenshots quickly.

Cons of Server-Side Appium

There are not many cons of Server-Side Appium as we get speed and stability. One possible con could be

Hard to Integrate with Other Local Systems 

The only potential drawback for the Server-Side Appium could be that if you have tests integrated with other local systems, it would become very hard to trigger the test execution over on the server side and trigger the following tasks on your local machines.

Which One to Use?

It’s clear that the Server-Side Appium approach is a way better approach than the Client-Side Appium approach. Not only can you enjoy the benefits of parallel device testing and alleviate the pain of maintaining scripts for executing tests, but also it greatly improves team productivity and trustworthiness of tests that Client-Side Appium couldn’t provide.

Bitbar offers both ways for executing Appium tests. Though Client-Side Appium is still beneficial for quick sanity tests, Server Side Appium is highly recommended for larger regression test suites to speed up and scale your mobile app testing.


The Beginner’s Guide of Using Appium for Mobile App Testing

Learn all the basics about Appium, how to set it up and how to use it for mobile app testing.

Download