Instrumentation Testing

In this document * Instrumentation Framework * Platform Test Suites * Running Tests * Writing Tests * Troubleshooting This document describes how to use the Instrumentation Framework to write test cases. Instrumentation testing allows you to verify a particular feature or behavior with an automated JUnit TestCase. You can launch activities and providers within an application, send key events, and make assertions about various UI elements. You should have a working knowledge of the following: * Android Application Framework * Using adb, am and various logging functionality * A brief understanding of the application of interest, that is, the names of the classes which handle the intents etc. * JUnit testing. Each Android application runs in its own process. Instrumentation kills the application process and restarts the process with Instrumentation. Instrumentation gives a handle to the application context used to poke around the application to validate test assertions, allowing you to write test cases to test applications at a much lower level than UI screen shot tests. Note that Instrumentation cannot catch UI bugs. Instrumentation Framework Classes The following classes help glue together Instrumentation with JUnit testing. Class Description InstrumentationTestCase This extends the standard JUnit TestCase and offers access to an Instrumentation class. Write tests inside your instrumentation class any way you see fit. For example, your test might launch activities and send key events. For this to work properly, the instrumentation needs to be injected into the test case. InstrumentationTestRunner The instrumentation test runner is an instrumentation that runs instrumentation test cases and injects itself into each test case. Instrumentation test cases need to be grouped together with an instrumentation test runner with the appropriate target package. InstrumentationTestSuite The instrumentation test suite is a simple extension of the standard JUnit TestSuite that keeps a member Instrumentation variable on hand to inject into each TestCase before running them. It is used by InstrumentationTestRunner. Three additional base classes extend InstrumentationTestCase to allow you to test Activity and Provider classes: Class Description ActivityTestCase This class can be used to write tests for a specific activity. An activity is launched in its setUp() method and finished with tearDown. If you write a test case that extends ActivityTestCase, you can write tests that access the activity using getActivity() and assume it has been set up properly. ServiceTestCase This test case provides a framework in which you can test Service classes in a controlled environment. It provides basic support for the lifecycle of a Service, and hooks by which you can inject various dependencies and control the environment in which your Service is tested. SingleLaunchActivityTestCase This class is similar to ActivityTestCase except that the activity is launched once per class instead of every time the test case calls setup. ProviderTestCase This class is similar to ActivityTestCase except that it will setup, tear down, and provide access to the Provider of your choice. Understanding the am Command The am command is a command-line interface to the ActivityManager (see http://code.google.com/android/reference/android/app/ActivityManager.html for details). am is used to start and instrument activities using the adb shell command, as shown in the snippet below: > adb shell am usage: am [start|instrument] am start [-a <action>] [-d </action>