This document describes how to run tests directly from the command line. This document assumes that you already know how to create an Android application and write tests for your app. For more information on how to build tests for your app, see Test apps on Android.
When you build your app using the Gradle build system, the Android Gradle plugin lets you run tests from your Gradle project using the command line. For more fine-grained control, you can also choose to run your tests through an Android Debug Bridge (adb) shell.
Run tests with Gradle
The Android Gradle plugin lets you run tests from your Gradle project using the command line.
The table below summarizes how to run your tests with Gradle:
|Unit test type||Command to run||Test result location|
|Local unit test||
HTML test result files:
XML test result files:
|Instrumented unit test||
HTML test result files:
XML test result files:
task name abbreviations.
This means, for example, you can initiate the
connectedAndroidTest task by
simply entering the following command.
You can also choose to run the Gradle tasks
tasks run your local or instrumented tests, respectively, but additionally
include other checks added by other Gradle plugins.
Run tests on a module
connectedAndroidTest tasks run tests on each module in your
project. You can run tests for just a specific module in your project by
prefixing the test or
connectedAndroidTest task with the module name and a
colon (:). For example, the following command runs instrumented tests for just
Run tests on a build variant
connectedAndroidTest tasks run tests on each
build variant in your project. You can target a
specific build variant using the following syntax.
- For local unit tests:
- For instrumented tests:
Run specific test methods or classes
When running local unit tests, Gradle allows you to target specific tests using
--tests flag. For example, the following command runs only the
sampleTestMethod tests for the specified build variant. To learn more about
--tests flag, read Gradle's documentation on
./gradlew testVariantNameUnitTest --tests '*.sampleTestMethod'
Multi-module reports for instrumented tests
As described in table 1, Gradle saves instrumented test results in the
directory of each module that it tests. However, when running tests across
multiple modules, it may be useful to combine all the test results into a single
report. To generate a single report when running tests across multiple modules,
follow these steps:
In your project-level
build.gradlefile, add the following after the
apply plugin 'android-reporting'
apply(plugin = "android-reporting")
connectedAndroidTesttask with the
mergeAndroidReportstask. For example:
./gradlew connectedAndroidTest mergeAndroidReports
If you want to skip test failures in order for Gradle to finish running all remaining tests, add the
./gradlew connectedAndroidTest mergeAndroidReports --continue
When Gradle finishes running all your tests, it saves the combined results in the
Run tests with adb
When you run tests from the command line with Android Debug Bridge (adb), you get more options for choosing the tests to run than with any other method. You can select individual test methods, filter tests according to a custom annotation, or specify testing options. Since the test run is controlled entirely from the command line, you can customize your testing with shell scripts in various ways.
To run a test from the command line, run
adb shell to start a command line
shell on your device or emulator. Inside that shell you can interact with the
am command and use its
instrument subcommand to run your tests.
As a shortcut, you can start an adb shell, call
am instrument, and specify
command line flags all on one input line. The shell opens on the device or
emulator, runs your tests, produces output, and then returns to the command line
on your computer.
To run a test with
- Build or rebuild your main application and test package.
- Install your test package and main application Android package files (APK files) to your current Android device or emulator
At the command line, enter:
adb shell am instrument -w <test_package_name>/<runner_class>
<test_package_name>is the Android package name of your test application, and
<runner_class>is the name of the Android test runner class you are using. The Android package name is the value of the package attribute of the manifest element in the manifest file (
AndroidManifest.xml) of your test package. The Android test runner class is usually
adb shell am instrument -w com.android.foo/androidx.test.runner.AndroidJUnitRunner
Your test results appear in
am instrument flags
You can find a list of all the flags to use with the
am instrument command by
adb shell am help. Some important flags are described in the
Outputs results in raw format. Use this flag when you want to
collect performance measurements, so that they are not formatted as
test results. This flag is designed for use with the flag
Provides testing options as key-value pairs. The
||(none)||Disables restrictions on the use of hidden APIs. For more information on what hidden APIs are, and how this can affect your app, read Restrictions on non-SDK interfaces.|
am instrument options
-e <key> <value>
Some keys accept multiple values. You specify multiple values in a
comma-separated list. For example, this invocation of
provides multiple values for the
adb shell am instrument -w -e package com.android.test.package1,com.android.test.package2 \ > com.android.test/android.support.test.runner.AndroidJUnitRunner
The following table lists the key-value pairs you can use with your test runner.
||<Java_package_name>||The fully-qualified Java package name for one of the packages in the test application. Any test case class that uses this package name is executed. Notice that this is not an Android package name; a test package has a single Android package name but may have several Java packages within it.|
||<class_name>||The fully-qualified Java class name for one of the test case classes. Only this test case class is executed.|
|<class_name>#method name||A fully-qualified test case class name, and one of its methods. Only this method is executed. Note the hash mark (#) between the class name and the method name.|
Runs all test classes that extend
Runs all test classes that do not extend either
Runs a test method annotated by size. The annotations are
Runs all test classes that implement
||Runs tests in debug mode.|
Loads and logs all specified tests, but does not run them. The test
information appears in
Runs an EMMA code coverage analysis and writes the output to
Note: This option requires an EMMA-instrumented
build of the test application, which you can generate with the
Overrides the default location of the EMMA coverage file on the
device. Specify this value as a path and filename in UNIX format.
The default filename is described in the entry for the
When using the
-e flag, be aware of the following:
Bundlecontaining the key-value pairs.
packagekey takes precedence over the
classkey. If you specify a package, and then separately specify a class within that package, Android will run all the tests in the package and ignore the class key.
unitkey are mutually exclusive.
The following sections provide examples of using
am instrument to run tests.
They are based on the following structure:
- The test package has the Android package name
- Two instrumented test classes:
Foo1which contains the test method
Foo2which contains test methods
- The test runner is
Run the entire test package
To run all of the test classes in the test package, enter:
adb shell am instrument -w com.android.demo.app.tests/android.support.test.runner.AndroidJUnitRunner
Run all tests in a test case class
To run all of the tests in the class
adb shell am instrument -w \ > -e class com.android.demo.app.tests.Foo1 \ > com.android.demo.app.tests/android.support.test.runner.AndroidJUnitRunner
Select a subset of tests
To run all of the tests in the
Foo1 class, and the bar3 method in Foo2, enter:
adb shell am instrument -w \ > -e class com.android.demo.app.tests.Foo1,com.android.demo.app.tests.Foo2#bar3 \ > com.android.demo.app.tests/android.support.test.runner.AndroidJUnitRunner
You can find more use cases in the