Technical docs‎ > ‎

Unit testing support

This page is obsolete. Redirecting you to Getting Started with Testing.

Version 1.1 of Android Studio and the Android gradle plugin brings support for unit testing your code on your development computer. We encourage you to try this feature and file any bugs you find in our bug tracker.

How it works

Unit tests run on a local JVM on your development machine. Our gradle plugin will compile source code found in src/test/java and execute it using the usual Gradle testing mechanisms. At runtime, tests will be executed against a modified version of android.jar where all final modifiers have been stripped off. This lets you use popular mocking libraries, like Mockito.

You will have to specify your testing dependencies in the build.gradle file of your android module. For example:

dependencies {
  testCompile 'junit:junit:4.12'
  testCompile "org.mockito:mockito-core:1.9.5"

Setting up Android Studio

To use unit testing support in AS, you have to do the following steps (click on the screenshots to see them in full size):
  1. Update build.gradle to use the android gradle plugin version 1.1.0-rc1 or later (either manually in build.gradle file or in the UI in File > Project Structure)

  2. Add necessary testing dependencies to app/build.gradle (see above).
  3. Sync your project.
  4. Open the "Build variants" tool window (on the left) and change the test artifact to "Unit tests".

  5. Create a directory for your testing source code, i.e. src/test/java. You can do this from the command line or using the Project view in the Project tool window. The new directory should be highlighted in green at this point. Note: names of the test source directories are determined by the gradle plugin based on a convention.
  6. Create your test. You can do this by opening a class, right-clicking it's name and selecting "Go to > Test". Add some test cases.
  7. Right click your new test class or method and select "Run ...".

Running from Gradle

To run your unit tests, just execute the test task: ./gradlew test --continue. If there are some failing tests, links to HTML reports (one per build variant) will be printed out at the end of the execution.

This is just an anchor task, actual test tasks are called testDebug and testRelease etc. If you want to run only some tests, using the gradle --tests flag, you can do it by running ./gradlew testDebug --tests='*.MyTestClass'.

Because test is just a shorthand for "testDebug testRelease", the --continue flag is needed if you want to make sure all tests will be executed in all build combinations. Otherwise Gradle could stop after testDebug (failing tests cause the task to "fail") and not execute testRelease at all. 

You can configure the Gradle runner, using the "all" block:

android {
  // ...
  testOptions { 
    unitTests.all {
       // All the usual Gradle options.
       jvmArgs '-XX:MaxPermSize=256m'

Flavors and build types support

Just as with production code, you can have unit tests specific for a given flavor or build type (see here). In general we recomment you keep unit tests in the source tree corresponding to the production code tree, that is:

 Production class  Test class
src/main/java/ src/test/java/
src/debug/java/ src/testDebug/java/
src/myFlavor/java/ src/testMyFlavor/java/

Note that when running tests from Gradle, we will execute tests for every variant of your code (see here). This means that tests will end up executing at least twice (once with the release build of your code, once with the debug build of production code).

"Method ... not mocked."

The android.jar file that is used to run unit tests does not contain any actual code - that is provided by the Android system image on real devices. Instead, all methods throw exceptions (by default). This is to make sure your unit tests only test your code and do not depend on any particular behaviour of the Android platform (that you have not explicitly mocked e.g. using Mockito). If that proves problematic, you can add the snippet below to your build.gradle to change this behavior:

android {
  // ...
  testOptions { 
    unitTests.returnDefaultValues = true

We are aware that the default behavior is problematic when using classes like Log or TextUtils and will evaluate possible solutions in future releases.