Work for Mobile Apps and Games

We’ve been discussing different angles and flavors of Selenium / Appium in mobile app testing, and I wanted to write down a brief blog about how you can use your existing Selenium tests also in mobile app/game context. Many of you – or some web developers out there – have used Selenium for desktop, PC-powered web testing 7-8 years and basically today the very same logic and functionality is provided for creating those tests for mobile apps and games today.

Appium, APK and IPA, and Different Android API Level

Some people have been confused when we talk about Appium and Selenium in the same sentence. In a nutshell: Appium is a mobile test automation framework (plus inspecting tool) for native, hybrid and mobile web apps for iOS and Android. It uses JSONWireProtocol internally to interact with iOS and Android apps using Selenium’s WebDriver. In few words, what works with Selenium, likely works with Appium as well. This is because the framework is basically a wrapper that translates Selenium Webdriver commands into UI Automation (iOS) or uiautomator (Android, API level 17 or newer) or Selendroid (Android, API level 16 or lower) commands depending on the device type. Do not forget to check out the Selenium Toolkit our friends at CrossBrowserTesting put together to guide you through the steps of getting started with Selenium.

Mobile Automation: Android & iOS Automation Testing Tool

Appium has basically two different ways to use it for getting your app, game or some web piece tested. For example, many popular Android mobile apps/games get tested with Appium Client-Side tests. This is the original idea of how test automation should work – and probably slightly even primitive, as you can’t easily handle parallel test runs or not at least start those. This also requires some configurations every now and then as you need to set up Selenium desired capabilities. Better option – and one to help you to get rid of those desired capabilities – is to use Appium Server-Side tests. In this case, you don’t run a test from your localhost, but you just upload your .APK or .IPA and test package to Bitbar Testing and the system takes care of a proper configuration and manages all details for desired capabilities.

How Are These Approaches Different – How those Work?

Working with Selenium – and Selenium testing – is very easy and you will learn it quickly. First, something else: take a look at Selenium IDE, which is a Firefox plugin and records and plays back user interactions with the browser. Use this to either create simple scripts or assist in exploratory testing. It exports those scripts for WebDriver. Then, as said, the app is uploaded to Bitbar Testing the same way in both approaches. You can do it manually by logging in, select project, and upload the file – or you can 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.

Also, worth of mentioning, but all the other features work seamlessly with the server-side Appium and you can – for example – configure and create new Android or iOS 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 – and get your tests running earlier as you don’t need to play with those desired caps. To get your tests running, you can select native Android project or more specifically Selenium Android and/or Selenium iOS for project types you should be seeing under project configuration.

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. It’s worth of mentioning that with the release of Selenium 2.0, the Selenium Server also included built-in Selenium Grid functionality which can help you to scale/distribute tests on several machines ( helps in local parallel execution).

Desired Capabilities – Get Rid of Those with Server Side Appium

Let’s look at things from localhost and Bitbar Testing. When you run any Appium / Selenium tests, you configure desired capabilities accordingly and point Webdriver either to localhost (https://localhost:4723/wd/hub) or Bitbar Testing (https://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_username”: “user@domain.com”,
“testdroid_password”: “p4s$w0rd”,
“testdroid_target”: “ios”,
“testdroid_project”: “My First Project”,
“testdroid_testrun”: “Test 1”,
“testdroid_device”: “iPad Mini 7.0.4 A1432”,
“testdroid_app”: “application.ipa”
.
.
“app”: “com.bitbar.testdroid.BitbarIOSSample”
}

What Happens to Your App on Bitbar Testing

In addition, the usability being light-year ahead on server-side Appium, those two pretty similar from the infrastructural point of view. This picture below explains what happens behind the scenes regardless of which way you are 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.

Why Use Appium Server-Side Execution

Clearly, one the most significant improvement 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. Furthermore, as Appium provides a cross-platform approach for Android automation testing and iOS automation testing you can also run tests on both platforms, at the same time (different device groups though).

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 a 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 on 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.