We’ve been discussing about different angles and flavors of Selenium / Appium in mobile app testing, and I wanted to write down a brief blog about how your 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 commands depending on the device type. Do not forget to download our free beginner’s guide and learn how to set up a proper Appium/Selenium testing environment step-by-step.
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 of 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 test from your localhost, but you just upload your .APK or .IPA and test package to Testdroid Cloud 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 Testdroid Cloud 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 Testdroid 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 Testdroid API (as a test file) or use the manual web front-end.
Also, worth of mentioning, but all the other Testdroid Cloud 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 Testdroid desired capabilities and make sure everything is ready for execution on Testdroid Cloud. 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 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 Testdroid Cloud 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 both, localhost and Testdroid Cloud point of view. When you run any Appium / Selenium tests, you configure desired capabilities accordingly and point Webdriver either to localhost (
http://localhost:4723/wd/hub) or Testdroid Cloud (
http://appium.testdroid.com/wd/hub). For example, if you use Testdroid Cloud you also add Testdroid 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 details of it.
What Happens to Your App on Testdroid Cloud
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 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 aren’t any limitation of how many devices you can use simultaneously so even hundreds of different variants if you want.
Why Appium Server-Side – and Why Should You Take A Look At It
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 time, we’ve now extended the possibility to use it across even hundreds of real devices simultaneously. Furthermore, as Appium provides 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 the variety of errors that typically came with configuring devices in script.
Also, all test runs are now easy to monitor through real-time views at Testdroid Cloud. At a glance, you will see how test runs are doing, get instant feedback on failures, and possibility to maintain all test results (screenshots, logs, performance stats etc.) and file assets under your projects.
Professional Appium Tip
Want an access to Server-Side Appium? Please let us know (sales at bitbar dot com) and let us know in comment section what you think about this feature! So weigh in with comments – we’re looking for those!
Learn all the basics about Appium, how to set it up and how to use it for mobile app testing.Download