This is the 15th blog in our 37 Things You Should Know About Appium blog series. There are certain limitations that each framework as well as 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 ADB (Android Debugging Bridge) 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. In many situations this may be true, but here in Testdroid 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.
ADB commands via Server-side Appium
Testdroid offers so called Server-side Appium execution, where the Appium Client is executed on the same host as the Appium Server. The main benefit of this is that it is much more efficient way to scale to high amount of test devices. As in normal Appium’s case, you’re launching test for one device (and can only launch one device per instance) we get to use the Testdroid’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 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 on 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 at Github as well as Testdroid Cloud 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 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 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!