Setting up Android devices for Espresso tests with Testdevicemanager
UI tests are an important part of our test pyramid at the WELT Mobile Native development team. That’s why we continuously put an effort not only into extending the UI test coverage but also into making the whole process smoother and automate more and more parts of it whenever possible.
Several issues were causing our UI tests to fail and resulted in time-consuming investigations that could have been avoided if the test devices were set up correctly. These issues were, for example:
- being connected to a wrong WiFi
- stay awake mode was not activated and the device turned off the screen during the test
- animations were enabled when the tests started
Setting up the devices automatically before each test run would solve the problems we were facing. There was also the requirement to not add any additional access rights to our app nor use rooted devices. That’s how the idea of a Gradle plugin manipulating and checking real devices arose.
We implemented an open-source solution called it Testdevicemanager and in this article, we want to describe to you what the plugin is capable of and how you can use it.
Currently, Testdevicemanager is able to:
- Lock / unlock a device
- Enable / disable animations
- Enable / disable “stay awake” mode
- Checking for connection to a specific WLAN
- Checking / setting device language
You can check out the repo on Github:
Preconditions
There are some preconditions that need to be met before you can use the plugin. Don’t worry though, it is nothing more than setting up the device for running Espresso tests with Android Studio:
- Connect the test device to the machine that creates the build.
- The developer options need to be activated on the Android device.
- Establish a working ADB connection between your machine and your test device.
Integration into the project
In order to integrate the Testdevicemanager plugin into your project, you have to add the following code to your project’s build.gradle file
In case you are using the plugins DSL:
Or for the legacy plugin application:
How it works
Let’s see how we can invoke adb shell commands from inside the plugin. First, we need to create an instance of AppExtension which will enable us to find the location of the adb-executable. We need this to create an instance of AndroidDebugBridge which is provided by thecom.android.ddmlib library. The AndriodDebugBridge then enables us to access all the devices that are attached, represented as instances of IDevice. This class enables the plugin to run adb shell commands on connected devices and emulators in order to gather system information and set up the device. This way the test device does not have to be rooted and no additional access rights have to be granted. All these steps are put into a Gradle plugin and executed as a respective task.
Features
Now let’s have a look at the features Testdevicemanager plugin offers and how to set them up.
In your module’s build.gradle file apply the plugin and create a specific closure to configure the plugin:
Locking test devices
Gradle task: connectedDeviceLock
No configuration is needed. Locks the device by “pressing the power button” (sending the input event) if the display is switched on.
Unlocking test devices
Gradle task: connectedDeviceUnlock
By Power Button: Presses the power button when the device display is deactivated
By swipe: Presses the power button to activate the display and swipe from the bottom to the upper right corner.
By pin: Presses the power button to activate the display and enter the pin that is provided. Presses “ok” afterwards.
By password: Presses the power button to activate the display and enters the password that is provided. Presses “ok” afterwards.
Disable animations on the test device
Gradle task: connectedAnimationsDisable
No configuration needed. Saves the current animation values in a local text file with separate entries for each connected device and sets the value on each device to “0”.
Enable animations on the test device
Gradle task: connectedAnimationsEnable
No configuration needed. By default, sets all animation values to “1” on the device. In case animations were already disabled by Testdevicemanager plugin for this device, it restores the saved animation values from a local text file.
Enable the test device to stay awake
Gradle task: connectedStayAwakeEnable
No configuration needed. Activates stay awake mode, so the display will be kept active.
Disable the test device to not stay awake
Gradle task: connectedStayAwakeDisable
No configuration needed. Deactivates stay awake mode, so the display won’t be kept active.
Check for specific wifi connection
Gradle task: connectedCheckWifi
Checks if the test device is connected to the WLAN with the provided name (SSID). Throws an exception, if the device is not connected to that specific WLAN.
Check for a specific language to set on the test device
Gradle task: connectedCheckLanguage
Checks for a specific language to set on the test device. Throws an exception, if the language is different than expected.
Set specific language on the test device
Gradle task: connectedSetLanguage
In order to do this, you need to install ADB Change Language from Google Play first and grant the necessary access rights. Testdevicemanager plugin then triggers the app to change the system language. This works without rooting your test device. Throws an exception, if ADB Change Language is not installed on the device or if the language cannot be set.
Running Testdevicemanager plugin in Android Studio
After correct integration of the plugin, in the Gradle menu, you will find a task group called device setup. If you expand it, you can see all the available tasks that were described in the former paragraph.
If you set up the plugin correctly you can double click on one of these tasks and Android Studio will run it on every connected device.
Using the plugin in Jenkins
If Espresso tests are part of your CI process, it might be handy to set up or check your test devices before each test suit run. The Gradle tasks provided by Testdevicemanager can easily be triggered by your CI system.
We will use Jenkins as an example here: First setup Testdevicemanager according to your needs as described above in your modules build.gradle file. Then navigate to the settings page of your Jenkins job and check for the “Build” section. Here you can invoke Gradle scripts. Just chose the Gradle tasks you want to be run during your build and your connected test devices will react accordingly.
To trigger Gradle tasks after the build is done and your tests are executed, you can check the “Post-build Actions” section. Here you can also invoke Gradle scripts.
Final thoughts
By integrating Testdevicemanager in our CI process, we could reduce the amount of time spent for setting up test devices and investigating setup related test failures a lot. What’s more, we could make our test more error-prone since there were no more struggles due to activated animations, wrong language settings and missing internet connection. Another advantage is that we can now easily integrate the plugin to any other Android project and benefit from it in the respective UI tests.
If you have any ideas for useful features that should be added, reach out to us or contribute to the repo ( https://github.com/spring-media/apps-android-testdevicemanager )!
Please let us know if you like the plugin and the manual we gave here by leaving a clap or a comment. Feel free to visit the repo and make sure to have a look at the other articles at Axel Springer Tech blog here on Medium.
I also want to say “thank you” to Paulina Strychacz who was reviewing this article extensively and also improved the implementation of the plugin a lot.
