Appium has been the number one smoking hot framework and there are no signs of this trend cooling down anytime soon. To make things even more convenient for our users, we’re about to introduce an awesome new feature that will make executing those test runs much easier and less error-prone – as you don’t have to play those desired caps all the time.
Basically, the new feature allows users to run Appium/Selenium scripts with no need to configure desired capabilities as they would do with current client-side execution. We call this implementation “Appium Server Side” execution that basically means that test scripts can run locally on our environment – you just upload your .APK or .IPA and test package to Bitbar Testing and our system takes care of proper configuration and manages all details for desired capabilities.
How Does It Work?
The application is uploaded to Bitbar Testing the same way in both approaches. You can do it manually or use the Bitbar API to get your application file (APK or IPA) included in the project where test execution will take its place. Also, the test package (as a zip file including all test assets, script, etc.) can be uploaded the same way as you would be doing with other test automation frameworks. Like the application file, you can push the test zip package through Bitbar API (as a test file) or use the manual web front-end.
The great news is that all the other features work seamlessly with the server-side Appium and you can – for example – configure and create new device groups and run those tests within these device groups without any modifications to desired capabilities. This itself can save you hours from configuration time.
With Client-Side Appium you will need to configure those Bitbar desired capabilities and make sure everything is ready for execution on Bitbar Testing. The test script will then go through and communicates with Appium Broker that passes all configuration details to Appium Server and then to the device (one device at a time). The server-side Appium does this parallel with all selected devices, making the whole process much faster.
Both approaches will allow you to reserve all test assets (scripts, screenshots, logs, etc.) under your Bitbar Testing projects, but with server-side Appium all other features are available and easy to use.
Desired Capabilities – And How to Get Rid of Those
When you run any Appium tests, you configure desired capabilities accordingly and point Webdriver either to localhost (
http://localhost:4723/wd/hub) or Bitbar Testing (
http://appium.testdroid.com/wd/hub). For example, if you use Bitbar Testing you also add Bitbar Desired Capabilities for your test script – for example like this:
“testdroid_project”: “My First Project”,
“testdroid_testrun”: “Test 1”,
“testdroid_device”: “iPad Mini 7.0.4 A1432”,
There are few more options for configuring desired capabilities, so please check this if you want to know all the details of it.
Behind the Scenes
Despite the usability is much more smooth with server-side Appium, from the infrastructural point of view both are pretty similar. The picture below illustrates what happens behind the scenes regardless of which way the user is using it.
The things behind the scene are pretty much the same regardless of which approach you to take. If you use client-side execution, you must configure those desired caps and our Appium Broker together with Appium Server takes care of running tests one by one on those devices. With server-side Appium execution, our system takes care of simultaneous test runs on those devices you have selected. There isn’t any limitation of how many devices you can use simultaneously so even hundreds of different variants if you want.
The Benefits of Server-Side Appium
First of all, one of the most significant improvements provided with this server-side Appium implementation is the ability to execute Appium tests parallel on real devices. As Appium was originally designed to provide tight relation to emulator or one device at a time, we’ve now extended the possibility to use it across even hundreds of real devices simultaneously.
Secondly, users do not need to configure any of those devices on desired capabilities, but all can be done with Device Group creation and configuration by dragging and dropping desired devices into your device groups. This eliminates the variety of errors that typically came with configuring devices in the script.
Also, all test runs are now easy to monitor through real-time views at Bitbar Testing. At a glance, you will see how test runs are doing, get instant feedback on failures, and the possibility to maintain all test results (screenshots, logs, performance stats, etc.) and file assets under your projects.