In this tutorial, we will "create" some UI tests for an Android application using Espresso testing library.
Tests can be written either in Java or Kotlin.
- gradle 5.6
- Android SDK (e.g. v28)
- (optional) Android Studio
The Android application is quite simple: it contains two activities, where the main one as an input to change some text along with two buttons that will give the possibility to change the text in the current activity of in a new one.
The code related to the previous activities can be found here.
The project contains 2 tests, implemented both in Java and in Kotlin (thus, overall 4 tests although 2 "duplicated").
Espresso provides ways of interacting with the UI and assertions that can be used to perform checks in your tests.
There are different types of tests: local unit tests (i.e. unit tests that don't need a device/emulator) and instrumentation tests (which run on a device/emulator).
Depending on which tests, checks and tasks you want to run, the
gradle syntax needs to be adapted accordingly; you may use "
gradle tasks" (or "
gradlew tasks") to find out all available tasks.
Thus, you'll find multiple ways of running the tests using the command line.
For local unit tests, you may use:
gradle clean cleanTest test
In this case, test results will be stored as multiple JUnit XML files in build/test-results.
For instrumentation tests, you may use:
In this case, test results will be stored as one JUnit XML file in a directory similar to
If you're using Android Studio, then you can also use it to write and run your tests.
However, if you decide to manually export the results to an XML file, that format is not a JUnit XML compatible one in is thus not supported.
To run the tests during CI, we can invoke
You may start an emulator from within Android Studio (Tools => AVD Manager).
You may also use the command line, for example:
emulator -avd Pixel_XL_API_29
If you need to find out the name of the AVD, you may use:
After running the tests and generating the JUnit XML report(s) (e.g., TEST-Pixel_XL_API_29(AVD) - 10-app-.xml), it can be imported to Xray (either by the REST API or by using one of the CI plugins or through Import Execution Results action within the Test Execution).
A Test Execution will be created containing information about the executed scenarios.
Each test is mapped to a Generic Test in Jira, and the Generic Test Definition field contains the name of the class concatenated with the method name of the corresponding automated test.
The Execution Details of the Generic Test contains information about the "Test Suite" (as per JUnit format), which in this case corresponds to the first test full classpath.
You can also import local unit tests. Note that you'll have a JUnit XML file per test class. You may use junit-merge utility in case you want to merge all these reports to a single JUnit XML report.