This is the 15th blog in our Things You Should Know About Appium blog series. There are certain limitations that each framework and programming language have so this time around we’ll focus on how to break off from the limitations and how to use some conventional mechanisms during your test runs. For example Android Debugging Bridge (ADB) and how to use it in the context of Appium. Naturally, this is only available and usable with Android. More importantly, ADB is usable and actually very handy when used together with Appium and test runs on execution. This works well for testing native apps, but also with mobile games using image recognition. Furthermore, not only with Appium, but literally with any test automation framework you could use our image recognition method or dynamic scripting with real-time inspection of log data. Let’s dive deeper.
Whenever people talk about test automation with some specific test framework, you would think that you are completely tied and limiting yourself to using just the API of the chosen platform. This may be true in many situations, but we do have some hacks and advanced workarounds to break off from the chains of closed framework test automation. The more open, usable and inline with open standards the implementation is, the better. Do not forget to download our free Appium beginner’s guide to verify if you have a proper Appium environment.
ADB commands via Server-side Appium
Bitbar Testing offers Server-Side Appium execution, where the Appium Client is executed on the same host as the Appium Server. Its main benefit is that it is a much more efficient way to scale to a large number of test devices. As in normal Appium’s case, you’re launching the test for one device (and can only launch one device per instance) we get to use the Bitbar’s own queuing system so that the tests start executing as soon as each device on chosen device group becomes available. This is the true parallelism and provides a neat way to run tests simultaneously even on hundreds of real devices. For some reason, this wasn’t well taken into consideration with Appium in the early days.
All the device sessions are executed in individual and isolated containers, which gives us the possibility to allow our customers to execute shell scripts and also
adb commands before, during and after test execution. This is very powerful when you want to break off from the test framework restrictions and use for example
adb commands during your tests also in the cloud.
Here is an example of ADB commands from a Java-based test script, where I force the Google Play Store app to close and then launch right after:
Runtime.getRuntime().exec("adb shell am force-stop com.android.vending"); Runtime.getRuntime().exec("adb shell am start -n com.android.vending/com.google.android.finsky.activities.MainActivity");
See ADB shell documentation for all ADB commands. Note that using ADB commands via Client side Appium test scripts won’t work for a remote server, because the ADB commands will be executed on your own workspace instead of the remote server hosting the devices.
Image recognition is one way for us to detect elements from apps that don’t use native UI elements. Our image recognition technology is based on open sourced OpenCV and we do have a local sample available on Github and Bitbar Testing integration related help page to get you started.
Image recognition is a premium feature, since we’re still working to improve the testing process and will be offering dedicated support if you decide to evaluate this testing method. Take a look at this video to get a good idea of how the image recognition process works.
Dynamic Log Scripting
This is a concept we have had success with before and a public sample is under development. The idea is to make the tested app output all the coordinate data through logs of the tested app and have scripts access that data in realtime. The test framework script has access to the log stream and will know about the coordinate data when executing gestures on the device screen.
This concept is one option next to Image recognition for apps that don’t use native UI elements (e.g. Unity game engine apps). The downside is that it does require the tested app to have custom log output, which means extra work for the developers of the app. We are however working on a tool to make the generation of the correct type of log stream available for Unity.
Happy Holidays everyone! We’ll be continuing next week with a new topic so stay hungry and keep testing! And remember that test automation can take care of your testing – despite of holidays!