Continuous Integration

Unit test coverage report with Travis CI for Robolectric on Android

2017-03-19 Android, Continuous Integration, DSP2017, Gradle, Unit Tests No comments


Some time ago, I’ve written an article about Test coverage report for Android application. It got some interest (many comments below article and many visits according to Google Analytics), so I decided to refresh this topic. Previously, I’ve written instrumentation unit tests, which needed to be executed on a real device or an emulator. It’s a good approach when you want to test functionalities strongly connected with the device. E.g. when you want to test operations on a real SQLite database or something like that. Nevertheless, this approach has huge disadvantages. It’s hard to run tests on the Continous Integration server because we need to have the emulator or device up & connected all the time and also tests need to interact properly with the device to get passed what is not so easy. In most cases, mocking part of the application’s behavior is enough. In that case, we can easily run tests on a CI server and have deterministic test results. In order to do that, we can use Robolectric.

Gradle configuration

First, we have to add appropriate dependency to jacoco-android plugin in our top-level build.gradle file:

buildscript {
  repositories {
  dependencies {
    classpath ''
    classpath 'com.dicedmelon.gradle:jacoco-android:0.1.1'

Next, we need to add appropriate test dependencies in another build.gradle file for our app or library.

dependencies {
  testCompile 'junit:junit:4.12'
  testCompile ''
  testCompile 'org.robolectric:robolectric:3.1.2'
  testCompile 'org.mockito:mockito-core:2.7.17'

I’ve added also dependencies to JUnit, Truth and Mockito library, which are used in my tests.

We also need to add appropriate plugins:

apply plugin: 'jacoco'
apply plugin: 'jacoco-android'

To avoid ignoring our tests by the coverage report, we need to configure the following settings:

android {
  testOptions {
    unitTests.all {
      jacoco {
        includeNoLocationClasses = true

Next, we need to configure report output:

jacocoAndroidUnitTestReport {
  csv.enabled false
  html.enabled true
  xml.enabled true

Travis CI configuration

We are done with Gradle configuration. I’m assuming we have Travis CI build configured. If you don’t know, how to do this, visit and enable builds for your project. It’ pretty easy. Now, we should visit website, register there (e.g. with GitHub account) and add our project. After that, we need to add the following items to our .travis.yml file:

  - bash <(curl -s

  - ./gradlew clean build test jacocoTestReport check

Here we are performing clean, build an application, running unit tests, generating test coverage report with Jacoco and performing check (Lint, FindBugs, PMD & CheckStyle).

Writing unit tests with Robolectric

Next we can place our tests in src/test/ directory.
Sample unit test can look as follows:

In my case, I also needed to create src/test/resources/ file with the following content:


because Robolectric didn’t work with the Android SDK newer than 23. Moreover, I also needed to use Robolectric v. 3.1.2, because I had problems with running tests and generating coverage report with the latest version of the Robolectric.


When we have everything configured, we can push our tests to the GitHub repository, Travis CI build will be triggered and we can beautiful test coverage report, which can help to improve our tests.

We can also click on the main package and see detailed coverage information for the several packages.

Moreover, we can analyze coverage change in time.

I’ve applied approach described in this article in ReactiveNetwork open-source library. If want to see the complete solution, take a look at the source code of this project or see its coverage report on-line.

Test coverage report for Android application

2015-06-03 Android, Continuous Integration, Unit Tests 68 comments

Update: see newer article about Unit test coverage report with Travis CI for Robolectric on Android.

For a long time, I wasn’t able to find the right way to generate test coverage reports for Android instrumentation unit tests created with AndroidJUnit4 runner. In the past I’ve found many solutions, but none of them was working or they were compatible only with Robolectric, which I currently don’t use. Other developers also stopped using it for the new projects. E.g. Sqlbrite from Square is using AndroidJUnit4 runner as my projects do. Recently, I’ve found an interesting discussion on Reddit, where we can find information about enabling test coverage very easily without additional plugins, scripts and many lines of configuration. Moreover, Android SDK currently has built-in support for Emma Test Coverage, what we can read in official documentation.

Basically, the only thing we need to do, is to apply jacoco-android plugin in build.gradle file:

apply plugin: 'jacoco-android'

and then set testCoverageEnabled parameter to true as follows:

android {
   buildTypes {
      debug {
         testCoverageEnabled = true

In order to create test coverage report, we need Android device or emulator connected to the computer, because connectedCheck task needs to be executed before creating the report.

Next, we can execute the following Gradle task from CLI:

./gradlew createDebugCoverageReport

Task will analyze code of our project in /src/main/java/ directory and unit tests placed in /src/androidTest/java/ directory.
After executing this task, we can find test coverage report in the following directory of the module:


When we open index.html file, we can see visual report from test coverage, which can be viewed in a web browser.
Moreover, in the same directory, we can find report.xml file, which can used for test coverage analysis on continuous integration server.
Besides mentioned files, Gradle will generate file in the following directory:


In some cases, we may need this file. E.g. if chosen Jenkins plugin or another tool will need it in order to generate test coverage report properly.

Below, you can see exemplary test coverage report for Prefser, which is an open-source Android library.


This report was generated with JaCoCo code coverage library.

After analyzing test coverage report, I’ve added a few new unit tests, slightly modified the project and managed to obtain 100% test coverage.


In order to publish our report on Jenkins CI, we can use test coverage plugins, but I am not sure about their stability. Another solution is HTML Publisher plugin. We can add post-build action and publish our test coverage report generated by default as HTML website inside Jenkins job. In my opinion, it’s quite convenient solution, because it is easy to set up and allows us to navigate to the code, browse uncovered lines, methods and branches.

Finally, with this clean and fast solution we can easily monitor test coverage of our Android projects, find bottlenecks and increase overall quality of the applications and libraries.

Static Code Analysis in Android project

2015-03-26 Android, Continuous Integration, Static Code Analysis, Unit Tests No comments


I’ve recently read great article telling how to improve quality and syntax of your Android code by Vincent Brison. It presents how to use tools like Checkstyle, Findbugs, PMD, and Android Lint for Static Code Analysis in Android project. Static Code Analysis allows us to keep consistency of the source code style and helps us to find errors, warnings, possible bugs, bottlenecks and ways to improve the projects. I highly recommend to use tools like those mentioned.


Visit repository at:
The most important files are:

We can run analysis by executing the following command:

./gradlew check

Besides that, we can run each command like checkstyle, findbugs, pmd or lint separately if we want to.
In addition, when we build the project with command:

./gradlew build

check command will be executed as well, because of the following line in quality.gradle file:

check.dependsOn 'checkstyle', 'findbugs', 'pmd', 'lint'

After that, we can find output with our reports in directory: app/build/reports/. Of course, we can customize output directory and names of the report files. In default configuration, check command with generate reports in HTML format. Only output from the checkstyle operation will be generated in XML format. We can customize findbugs, pmd and lint, to generate XML reports instead of HTML reports in quality.gradle file.

Sensitivity of the build

We can customize rules of the Static Code Analysis tools in restrictive and non-restrictive way.
In findbugs and pmd task, we can set ignoreFailures attribute as follows:

ignoreFailures = false

When it’s set to false, tasks will only generate reports, but when we set it to true, build will fail, when at least one error will be found.
In lint task, we can customize attribute abortOnError as follows:

abortOnError true

It will literally abort the build, when any lint error occur. Warnings will be ignored. When we want to ignore errors, we can set this attribute to false.

Static Code Analysis on CI server

When we want to perform Static Code Analysis on CI server, we can do it easily from the command line interface. If we want to automatically collect and analyze reports generated by mentioned tools, we should generate them in XML format instead of HTML, so they can be parsed by appropriate plugins. Mentioned tools can be easily integrated with Jenkins CI server.
We need the following plugins:

After installing those plugins, we can define post-build actions in our Jenkins Job, provide paths to the appropriate XML reports and then we can view results of the reports and trend graphs directly from web panel of our Jenkins server.

Exemplary trend graphs looks as follows:


If we have unit tests in our project, we can also generate test reports and monitor test trend.
In the chart below, failed build don’t have generated test reports that’s why chart may look strange. In addition, number of tests was decreased, because they were migrated from JUnit3 to JUnit4. In JUnit3 for some reason each test case is treated as an additional unit test. JUnit4 report shows real number of tests.


In every build, we can browse generated reports and their details.


I really recommend to use Static Code Analysis tools and reporting plugins on CI in the projects, because they will increase quality of the code really fast and will allow to eliminate many errors before shipping the application.