Professional Documents
Culture Documents
Testing is a critical software development activity because it helps you improve the quality of
your apps, ensure better user satisfaction, and reduce overall development time spent on
fixing defects.
The following sections describe tools that help you test your mobile apps for the Android
platform.
Android Testing Support Library
This library provides a set of APIs that allow you to quickly build and run test code for
your apps, including JUnit 4 and functional user interface (UI) tests. The Android
Testing Support Library includes the following test automation tools:
Monkey
This tool runs on your emulator or device and generates pseudo-random streams of
user events such as clicks, touches, or gestures, as well as a number of systemlevel events. You can use the Monkey tool to stress-test applications that you are
developing, in a random yet repeatable manner.
monkeyrunner
This testing system provides an API for writing programs that control an Android
device or emulator from outside of Android code.
The Android Testing Support library is available through the Android SDK Manager. For
more information, see Testing Support Library Setup
This page provides information about what tools are provided in the Android Testing Support
Library, how to use them in your testing environment, and information about library
releases.
AndroidJUnitRunner
The AndroidJUnitRunner class is a JUnit test runner that lets you run JUnit 3 or JUnit 4style test classes on Android devices, including those using the Espresso and UI
Automator testing frameworks. The test runner handles loading your test package and the
app under test to a device, running your tests, and reporting test results. This class replaces
theInstrumentationTestRunner class, which only supports JUnit 3 tests.
The key features of this test runner include:
JUnit support
Test filtering
Test sharding
JUnit support
The test runner is compatible with your JUnit 3 and JUnit 4 (up to JUnit 4.10) tests.
However, you should avoid mixing JUnit 3 and and JUnit 4 test code in the same package,
as this might cause unexpected results. If you are creating an instrumented JUnit 4 test
class to run on a device or emulator, your test class must be prefixed with
the@RunWith(AndroidJUnit4.class) annotation.
Test filtering
In your JUnit 4.x tests, you can use annotations to configure the test run. This feature
minimizes the need to add boilerplate and conditional code in your tests. In addition to the
standard annotations supported by JUnit 4, the test runner also supports Android-specific
annotations, including:
@RequiresDevice: Specifies that the test should run only on physical devices, not on
emulators.
@SdkSupress: Suppresses the test from running on a lower Android API level than
the given level. For example, to suppress tests on all API levels lower than 18 from
running, use the annotation @SDKSupress(minSdkVersion=18).
@SmallTest, @MediumTest, and @LargeTest: Classify how long a test should take
to run, and consequently, how frequently you can run the test.
Test sharding
The test runner supports splitting a single test suite into multiple shards, so you can easily
run tests belonging to the same shard together as a group, under the
same Instrumentation instance. Each shard is identified by an index number. When
running tests, use the -e numShards option to specify the number of separate shards to
create and the -e shardIndexoption to specify which shard to run.
For example, to split the test suite into 10 shards and run only the tests grouped in the
second shard, use the following command:
adb shell am instrument -w -e numShards 10 -e shardIndex 2
To learn more about using this test runner, see the API reference.
Espresso
The Espresso testing framework provides a set of APIs to build UI tests to test user flows
within an app. These APIs let you write automated UI tests that are concise and that run
reliably. Espresso is well-suited for writing white box-style automated tests, where the test
code utilizes implementation code details from the app under test.
The key features of the Espresso testing framework include:
Flexible APIs for view and adapter matching in target apps. For more information,
see View matching.
View matching
The Espresso.onView() method lets you access a UI component in the target app and
interact with it. The method accepts a Matcher argument and searches the view hierarchy
to locate a corresponding View instance that meets some given criteria. You can refine
searches by specifying such criteria as:
For example, to target a button that has the ID value of my_button, you can specify a
matcher like this:
onView(withId(R.id.my_button));
If the search is successful, the onView() method returns a reference which lets you
perform user actions and test assertions against the target view.
Adapter matching
In an AdapterView layout, the layout is dynamically populated with children views at
runtime. If the target view is inside a layout subclassed from AdapterView (such as
a ListView or GridView), the onView() method might not work because only a subset of
the layouts views may be loaded in the current view hierarchy.
Instead, use the Espresso.onData() method to access a target view element.
The Espresso.onData() method returns a reference which lets you perform user actions
and test assertions against the elements in an AdapterView.
Action APIs
Typically, you test an app by performing some user interactions against the apps user
interface. You can easily automate these actions in your test by using
the ViewActions API. You can perform such UI interactions as:
View clicks
Swipes
Typing text
Opening a link
For example, to simulate entering a string value and pressing a button to submit the value,
you can write an automated test script like this.
The ViewInteraction.perform() and DataInteraction.perform() methods take
one or moreViewAction arguments and run the actions in the order provided.
// Type text into an EditText view, then close the soft keyboard
onView(withId(R.id.editTextUserInput))
.perform(typeText(STRING_TO_BE_TYPED), closeSoftKeyboard());
// Press the button to submit the text change
onView(withId(R.id.changeTextBt)).perform(click());
UI thread synchronization
Tests on Android devices can fail randomly because of timing issues. This testing issue is
referred to as test flakiness. Prior to Espresso, the workaround was to insert a sufficiently
long sleep or timeout period into a test or to add code to keep retrying the failing operation.
The Espresso testing framework handles synchronization between
theInstrumentation and the UI thread; this removes the need for the previous timing
workarounds and ensures that your test actions and assertions run more reliably.
To learn more about using Espresso, see the API reference and Testing UI for a Single
App training.
UI Automator
The UI Automator testing framework provides a set of APIs to build UI tests that perform
interactions on user apps and system apps. The UI Automator APIs allows you to perform
operations such as opening the Settings menu or the app launcher in a test device. The UI
Automator testing framework is well-suited for writing black box-style automated tests,
where the test code does not rely on internal implementation details of the target app.
The key features of the UI Automator testing framework include:
A viewer to inspect layout hierarchy. For more information, see UI Automator Viewer.
An API to retrieve state information and perform operations on the target device. For
more information, see Access to device state.
APIs that support cross-app UI testing. For more information, see UI Automator
APIs .
UI Automator Viewer
The uiautomatorviewer tool provides a convenient GUI to scan and analyze the UI
components currently displayed on an Android device. You can use this tool to inspect the
layout hierarchy and view the properties of UI components that are visible on the foreground
of the device. This information lets you create more fine-grained tests using UI Automator,
for example by creating a UI selector that matches a specific visible property.
The uiautomatorviewer tool is located in the <android-sdk>/tools/ directory.
The UI Automator testing framework provides a UiDevice class to access and perform
operations on the device on which the target app is running. You can call its methods to
access device properties such as current orientation or display size. The UiDevice class
also let you perform actions such as:
For example, to simulate a Home button press, call the UiDevice.pressHome() method.
UI Automator APIs
The UI Automator APIs allow you to write robust tests without needing to know about the
implementation details of the app that you are targeting. You can use these APIs to capture
and manipulate UI components across multiple apps:
Configurator: Allows you to set key parameters for running UI Automator tests.
For example, the following code shows how you can write a test script that brings up the
default app launcher in the device:
// Initialize UiDevice instance
mDevice = UiDevice.getInstance(getInstrumentation());
// Perform a short press on the HOME button
mDevice().pressHome();
// Bring up the default launcher by searching for
// a UI component that matches the content-description for the
launcher button
UiObject allAppsButton = mDevice
.findObject(new UiSelector().description("Apps"));
To learn more about using UI Automator, see the API reference and Testing UI for Multiple
Apps training.