+
+Android includes powerful tools for setting up and running test applications. Whether you are working in Eclipse with ADT or working from the command line, these tools @@ -9,7 +8,7 @@ page.title=Testing Overview
If you aren't yet familiar with the Android testing framework, please read the topic - Testing and Instrumentation + Testing Fundamentals before you get started. For a step-by-step introduction to Android testing, try the Hello, Testing diff --git a/docs/html/guide/developing/testing/testing_eclipse.jd b/docs/html/guide/developing/testing/testing_eclipse.jd index da1c0f0b531d9..3258af9b4306a 100644 --- a/docs/html/guide/developing/testing/testing_eclipse.jd +++ b/docs/html/guide/developing/testing/testing_eclipse.jd @@ -1,28 +1,23 @@ page.title=Testing In Eclipse, with ADT @jd:body -
- This topic explains how create and run tests of Android applications in Eclipse with ADT. - - with the basic processes for creating and running applications with ADT, as described in - Developing In Eclipse, with ADT. - - Before you read this topic, you should read about how to create a Android application with the - basic processes for creating and running applications with ADT, as described in - Developing In Eclipse, with ADT. - You may also want to read - Testing and Instrumentation, - which provides an overview of the Android testing framework. + This topic explains how create and run tests of Android applications in Eclipse with ADT. + Before you read this topic, you should read about how to create a Android application with the + basic processes for creating and running applications with ADT, as described in + Developing In Eclipse, with ADT. + You may also want to read + Testing Fundamentals, + which provides an overview of the Android testing framework.
ADT provides several features that help you set up and manage your testing environment @@ -32,20 +27,20 @@ page.title=Testing In Eclipse, with ADT
<instrumentation> element in the test application's manifest file.
+ <instrumentation> element in the test package's manifest file.
+
To set up a test environment for your Android application, you must first create a separate
- application project that holds the test code. The new project follows the directory structure
+ project that holds the test code. The new project follows the directory structure
used for any Android application. It includes the same types of content and files, such as
- source code, resources, a manifest file, and so forth. The test application you
+ source code, resources, a manifest file, and so forth. The test package you
create is connected to the application under test by an
<instrumentation> element in its manifest file.
-
- The New Android Test Project dialog makes it easy for you to generate a
- new test project that has the proper structure, including the
- <instrumentation> element in the manifest file. You can use the New Android
- Test Project dialog to generate the test project at any time. The dialog appears just after you
- create a new Android main application project, but you can also run it to create a test project
- for a project that you created previously.
-
- To create a test project in Eclipse with ADT:
+ The New Android Test Project dialog makes it easy for you to generate a
+ new test project that has the proper structure, including the
+ <instrumentation> element in the manifest file. You can use the New
+ Android Test Project dialog to generate the test project at any time. The dialog appears
+ just after you create a new Android main application project, but you can also run it to
+ create a test project for a project that you created previously.
+
+ To create a test project in Eclipse with ADT:
+ The name becomes part of the suggested project path, but you can change this in the + next step. +
+/usr/local/workspace and your project name is
+ MyTestApp, then the wizard will suggest
+ /usr/local/workspace/MyTestApp. To enter your own
+ choice for a path, unselect Use default location, then enter or browse to the
+ path where you want your project.
+ + To learn more about choosing the location of test projects, please read + + Testing Fundamentals. +
++ Once you have created a test project, you populate it with a test package. This package does not + require an Activity, although you can define one if you wish. Although your test package can + combine Activity classes, test case classes, or ordinary classes, your main test case + should extend one of the Android test case classes or JUnit classes, because these provide the + best testing features. +
++ Test packages do not need to have an Android GUI. When you run the package in + Eclipse with ADT, its results appear in the JUnit view. Running tests and seeing the results is + described in more detail in the section Running Tests. +
+ ++ To create a test package, start with one of Android's test case classes defined in + {@link android.test android.test}. These extend the JUnit + {@link junit.framework.TestCase TestCase} class. The Android test classes for Activity objects + also provide instrumentation for testing an Activity. To learn more about test case + classes, please read the topic + Testing Fundamentals. +
++ Before you create your test package, you choose the Java package identifier you want to use + for your test case classes and the Android package name you want to use. To learn more + about this, please read + + Testing Fundamentals. +
++ To add a test case class to your project: +
+- -
-- Once you have created a test project, you populate it with a test - Android application. This application does not require an {@link android.app.Activity Activity}, - although you can define one if you wish. Although your test application can - combine Activities, Android test class extensions, JUnit extensions, or - ordinary classes, you should extend one of the Android test classes or JUnit classes, - because these provide the best testing features. + You now have to ensure that the constructor is set up correctly. Create a constructor for your + class that has no arguments; this is required by JUnit. As the first statement in this + constructor, add a call to the base class' constructor. Each base test case class has its + own constructor signature. Refer to the class documentation in the documentation for + {@link android.test} for more information.
- Test applications do not have an Android GUI. Instead, when you run the application in - Eclipse with ADT, its results appear in the JUnit view. If you run - your tests with {@link android.test.InstrumentationTestRunner InstrumentationTestRunner} (or a related test runner), - then it will run all the methods in each class. You can modify this behavior - by using the {@link junit.framework.TestSuite TestSuite} class. -
- -- To create a test application, start with one of Android's test classes in the Java package {@link android.test android.test}. - These extend the JUnit {@link junit.framework.TestCase TestCase} class. With a few exceptions, the Android test classes - also provide instrumentation for testing. -
-
- For test classes that extend {@link junit.framework.TestCase TestCase}, you probably want to override
- the setUp() and tearDown() methods:
+ To control your test environment, you will want to override the setUp() and
+ tearDown() methods:
setUp(): This method is invoked before any of the test methods in the class.
- Use it to set up the environment for the test. You can use setUp()
- to instantiate a new Intent object with the action ACTION_MAIN. You can
- then use this intent to start the Activity under test.
- Note: If you override this method, call
- super.setUp() as the first statement in your code.
-
tearDown(): This method is invoked after all the test methods in the class. Use
- it to do garbage collection and re-setting before moving on to the next set of tests.
- Note: If you override this method, you must call
- super.tearDown() as the last statement in your code.
setUp(): This method is invoked before any of the test methods in the class.
+ Use it to set up the environment for the test (the test fixture. You can use
+ setUp() to instantiate a new Intent with the action ACTION_MAIN.
+ You can then use this intent to start the Activity under test.
+ tearDown(): This method is invoked after all the test methods in the class. Use
+ it to do garbage collection and to reset the test fixture.
+
- Another useful convention is to add the method testPreConditions() to your test
- class. Use this method to test that the application under test is initialized correctly. If this
- test fails, you know that that the initial conditions were in error. When this happens, further test
- results are suspect, regardless of whether or not the tests succeeded.
+ Another useful convention is to add the method testPreconditions() to your test
+ class. Use this method to test that the application under test is initialized correctly. If this
+ test fails, you know that that the initial conditions were in error. When this happens, further
+ test results are suspect, regardless of whether or not the tests succeeded.
- The Resources tab contains an Activity Testing - tutorial with more information about creating test classes and methods. + The Resources tab contains an + Activity Testing + tutorial with more information about creating test classes and methods.
- If you've created your tests in Eclipse, you can still run your tests and test - suites by using command-line tools included with the Android SDK. You may want to - do this, for example, if you have a large number of tests to run, if you have a - large test case, or if you want a fine level of control over which tests are run at - a particular time. -
-
- To run tests created in Eclipse with ADT with command-line tools, you must first
- install additional files into the test project using the android tool's
- "create test-project" option. To see how to do this, read the section
-
- Creating a test project in the topic
- Testing in Other
- IDEs.
-
+ If you've created your tests in Eclipse, you can still run your tests and test + suites by using command-line tools included with the Android SDK. You may want + to do this, for example, if you have a large number of tests to run, if you + have a large test case, or if you want a fine level of control over which + tests are run at a particular time. +
+
+ To run tests created in Eclipse with ADT with command-line tools, you must first
+ install additional files into the test project using the android
+ tool's "create test-project" option. To see how to do this, read
+
+ Testing in Other IDEs.
+
- When you run a test application in Eclipse with ADT, the output appears in
- an Eclipse view panel. You can run the entire test application, one class, or one
- method of a class. To do this, Eclipse runs the adb command for running a test application, and
- displays the output, so there is no difference between running tests inside Eclipse and running them from the command line.
+ When you run a test package in Eclipse with ADT, the output appears in the Eclipse JUnit view.
+ You can run the entire test package or one test case class. To do run tests, Eclipse runs the
+ adb command for running a test package, and displays the output, so there is no
+ difference between running tests inside Eclipse and running them from the command line.
- As with any other application, to run a test application in Eclipse with ADT you must either attach a device to your - computer or use the Android emulator. If you use the emulator, you must have an Android Virtual Device (AVD) that uses - the same target + As with any other package, to run a test package in Eclipse with ADT you must either attach a + device to your computer or use the Android emulator. If you use the emulator, you must have an + Android Virtual Device (AVD) that uses the same target as the test package.
- To run a test in Eclipse, you have two choices:
-- Creating and running test configurations is described in the next section. -
-To create and run a test suite using a run configuration:
-- To run all the test classes, - click Run all tests in the selected project or package, - then enter the project or package name in the text box. -
-Note: Although you can run the test immediately by - clicking Run, you should save the test first and then - run it by selecting it from the Eclipse standard toolbar.
-Performing Android.test.InstrumentationTestRunner JUnit launch
- Automatic Target Mode: launching new emulator with compatible
- AVD avdname
(where avdname is the name of
- the AVD you are using.)
+ Creating and running test configurations is described in the next section.
+ To create and run a test suite using a run configuration: +
+
- Uploading testclass.apk onto device 'device-id'
- where testclass is the name of your unit test class and device-id
- is the name and port for your test device or emulator, followed by the message Installing testclass.apk
+ To run all the test classes, click Run all tests in the selected project or package,
+ then enter the project or package name in the text box.
Launching instrumentation Android.test.InstrumentationTestRunner on device device-id.Test run complete.Note: + Although you can run the test immediately by clicking Run, you should save the test + first and then run it by selecting it from the Eclipse standard toolbar. +
+
- The test results appear in the JUnit view. This is divided into an upper summary pane,
- and a lower stack trace pane.
+ The progress of your test appears in the Console view as a series of messages. Each message is
+ preceded by a timestamp and the Android package name to which it applies.
+ In the following description of these messages, devicename is the name of
+ the device or emulator you are using to run the test, and port is the
+ port number for the device. The name and port number are in the format used by the
+ adb devices
+ command. Also, testpackage is the name of the test package you are
+ running, and app_package is the label for the application under test.
+
+ HOME is up on device 'devicename-port'
+
+ Uploading testpackage onto device 'devicename-port'
+
+
+ then the message Installing testpackage.
+
+ and finally the message Success!
+
+ Project dependency found, installing: app_package
+
+ then the message Uploading app_name.apk onto device
+ 'devicename-port'
+
+ then the message Installing app_name.apk
+
+ and finally the message Success!
+
Launching instrumentation instrumentation_class on device
+ devicename-port
+
+ instrumentation_class is the fully-qualified class name of the
+ instrumentation test runner you have specified (usually
+ {@link android.test.InstrumentationTestRunner}.
+
+ Collecting test information
+
+ followed by +
+
+ Sending test information to Eclipse
+
Running tests, which indicates that your tests
+ are running. At this point, you should start seeing the test results in the JUnit view.
+ When the tests are finished, you see the console message Test run complete.
+ This indicates that your tests are finished.
+ + The test results appear in the JUnit view. This is divided into an upper summary pane, + and a lower stack trace pane.
- The upper pane contains test information. In the pane's header, you see the following - information: + The upper pane contains test information. In the pane's header, you see the following + information:
-The body of the upper pane contains the details of the test run. For each test case class that was run, you see a line with the class name. To look at the results for the individual diff --git a/docs/html/guide/developing/testing/testing_otheride.jd b/docs/html/guide/developing/testing/testing_otheride.jd index 2bdf4d0b0b70d..523a8e57f36e3 100644 --- a/docs/html/guide/developing/testing/testing_otheride.jd +++ b/docs/html/guide/developing/testing/testing_otheride.jd @@ -2,122 +2,128 @@ page.title=Testing In Other IDEs @jd:body
- This document describes how to create and run tests directly from the command line. - You can use the techniques described here if you are developing in an IDE other than Eclipse - or if you prefer to work from the command line. This document assumes that you already know how - to create a Android application in your programming environment. Before you start this - document, you should read the document Testing and Instrumentation, - which provides an overview of Android testing. + This document describes how to create and run tests directly from the command line. + You can use the techniques described here if you are developing in an IDE other than Eclipse + or if you prefer to work from the command line. This document assumes that you already know how + to create a Android application in your programming environment. Before you start this + document, you should read the topic + Testing Fundamentals, + which provides an overview of Android testing.
- If you are developing in Eclipse with ADT, you can set up and run your tests -directly in Eclipse. For more information, please read Testing in Eclipse, with ADT. + If you are developing in Eclipse with ADT, you can set up and run your tests + directly in Eclipse. For more information, please read + + Testing in Eclipse, with ADT.
- You use the android tool to create test projects.
- You also use android to convert existing test code into an Android test project,
- or to add the run-tests Ant target to an existing Android test project.
- These operations are described in more detail in the section Updating a test project.
- The run-tests target is described in Quick build and run with Ant.
+ You use the android tool to create test projects.
+ You also use android to convert existing test code into an Android test project,
+ or to add the run-tests Ant target to an existing Android test project.
+ These operations are described in more detail in the section
+ Updating a test project. The run-tests target is described in
+ Quick build and run with Ant.
- To create a test project with the android tool, enter:
-
android create test-project -m <main_path> -n <project_name> -p <test_path>+ To create a test project with the
android tool, enter:
+
++android create test-project -m <main_path> -n <project_name> -p <test_path> +
- You must supply all the flags. The following table explains them in detail: + You must supply all the flags. The following table explains them in detail:
| Flag | -Value | -Description | -
|---|---|---|
-m, --main |
- - Path to the project of the application under test, relative to the test application - directory. - | -
- For example, if the application under test is in source/HelloAndroid, and you
- want to create the test project in source/HelloAndroidTest, then the value of
- --main should be ../HelloAndroid.
+ |
| Flag | +Value | +Description | +
-m, --main |
+ + Path to the project of the application under test, relative to the test package + directory. | -|
-n, --name |
- Name that you want to give the test project. | -- |
-p, --path |
- Directory in which you want to create the new test project. | -
- The android tool creates the test project files and directory structure in this
- directory. If the directory does not exist, android creates it.
- |
-
+ For example, if the application under test is in source/HelloAndroid, and
+ you want to create the test project in source/HelloAndroidTest, then the
+ value of --main should be ../HelloAndroid.
+ + To learn more about choosing the location of test projects, please read + + Testing Fundamentals. + + |
+
+
-n, --name |
+ Name that you want to give the test project. | ++ |
-p, --path |
+ Directory in which you want to create the new test project. | +
+ The android tool creates the test project files and directory structure
+ in this directory. If the directory does not exist, android creates it.
+ |
+
If the operation is successful,
- For example, suppose you create the Hello, World tutorial application
- in the directory
Note: If you change the Android package name of the application under test,
you must manually change the value of the
@@ -205,38 +210,38 @@ $ android create test-project -m ../HelloAndroid -n HelloAndroidTest -p HelloAnd
android lists to STDOUT the names of the files
@@ -135,11 +141,10 @@ directly in Eclipse. For more information, please read
~/source/HelloAndroid. In the tutorial, this application uses the
- package name com.example.helloandroid and the activity name
- HelloAndroid. You can to create the test for this in
+ For example, suppose you create the
+ Hello, World tutorial application in the directory ~/source/HelloAndroid.
+ In the tutorial, this application uses the package name com.example.helloandroid
+ and the activity name HelloAndroid. You can to create the test for this in
~/source/HelloAndroidTest. To do so, you enter:
@@ -196,7 +201,7 @@ $ android create test-project -m ../HelloAndroid -n HelloAndroidTest -p HelloAnd
<android:targetPackage>
- attribute within the AndroidManifest.xml file of the test application.
+ attribute within the AndroidManifest.xml file of the test package.
Running android update test-project does not do this.
android update-test-project -m <main_path> -p <test_path>
| Flag | -Value | -Description | -
|---|---|---|
-m, --main |
- The path to the project of the application under test, relative to the test project | -
- For example, if the application under test is in source/HelloAndroid, and
- the test project is in source/HelloAndroidTest, then the value for
- --main is ../HelloAndroid.
- |
-
-p, --path |
- The of the test project. | -
- For example, if the test project is in source/HelloAndroidTest, then the
- value for --path is HelloAndroidTest.
- |
-
| Flag | +Value | +Description | +
-m, --main |
+ The path to the project of the application under test, relative to the test project | +
+ For example, if the application under test is in source/HelloAndroid, and
+ the test project is in source/HelloAndroidTest, then the value for
+ --main is ../HelloAndroid.
+ |
+
-p, --path |
+ The of the test project. | +
+ For example, if the test project is in source/HelloAndroidTest, then the
+ value for --path is HelloAndroidTest.
+ |
+
If the operation is successful, android lists to STDOUT the names of the files
and directories it has created.
- Once you have created a test project, you populate it with a test application. + Once you have created a test project, you populate it with a test package. The application does not require an {@link android.app.Activity Activity}, - although you can define one if you wish. Although your test application can + although you can define one if you wish. Although your test package can combine Activities, Android test class extensions, JUnit extensions, or ordinary classes, you should extend one of the Android test classes or JUnit classes, because these provide the best testing features. @@ -248,7 +253,7 @@ $ android create test-project -m ../HelloAndroid -n HelloAndroidTest -p HelloAnd
- To create a test application, start with one of Android's test classes in the Java package + To create a test package, start with one of Android's test classes in the Java package {@link android.test android.test}. These extend the JUnit {@link junit.framework.TestCase TestCase} class. With a few exceptions, the Android test classes also provide instrumentation for testing. @@ -282,24 +287,17 @@ $ android create test-project -m ../HelloAndroid -n HelloAndroidTest -p HelloAnd test results are suspect, regardless of whether or not the tests succeeded.
- To learn more about creating test applications, see the topic Testing and Instrumentation, + To learn more about creating test packages, see the topic Testing Fundamentals, which provides an overview of Android testing. If you prefer to follow a tutorial, try the Activity Testing tutorial, which leads you through the creation of tests for an actual Android application.
- If you are not developing in Eclipse with ADT, you need to run tests from the command line. - You can do this either with Ant or with the {@link android.app.ActivityManager ActivityManager} - command line interface. -
-
- You can also run tests from the command line even if you are using Eclipse with ADT to develop
- them. To do this, you need to create the proper files and directory structure in the test
- project, using the android tool with the option create test-project.
- This is described in the section Working with Test Projects.
+ You run tests from the command line, either with Ant or with an
+
+ Android Debug Bridge (adb) shell.
@@ -316,57 +314,63 @@ $ android create test-project -m ../HelloAndroid -n HelloAndroidTest -p HelloAnd
You can update an existing test project to use this feature. To do this, use the
android tool with the update test-project option. This is described
in the section Updating a test project.
+
- When you run tests from the command line with the ActivityManager (am)
- command-line tool, 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 their annotation, or
- specify testing options. Since the test run is controlled entirely from a command line, you can
- customize your testing with shell scripts in various ways.
+ 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 their annotation, or specify testing options. Since the test run is controlled
+ entirely from a command line, you can customize your testing with shell scripts in various ways.
- You run the am tool on an Android device or emulator using the
- Android Debug Bridge
- (adb) shell. When you do this, you use the ActivityManager
- instrument option to run your test application using an Android test runner
- (usually {@link android.test.InstrumentationTestRunner}). You set am
- options with command-line flags.
+ To run a test from the command line, you run adb shell to start a command-line
+ shell on your device or emulator, and then in the shell run the am instrument
+ command. You control am and your tests with command-line flags.
- To run a test with am:
+ 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 am instrument:
.apk files) to your current Android device or emulator.apk files) to your current Android device or emulator$ adb shell am instrument -w <test_package_name>/<runner_class>-
- where <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 application. The Android test runner
- class is usually InstrumentationTestRunner.
-
Your test results appear in STDOUT.
+ where <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 {@link android.test.InstrumentationTestRunner}.
+
+ Your test results appear in STDOUT.
+
- This operation starts an adb shell, then runs am instrument in it
+ This operation starts an adb shell, then runs am instrument
with the specified parameters. This particular form of the command will run all of the tests
- in your test application. You can control this behavior with flags that you pass to
+ in your test package. You can control this behavior with flags that you pass to
am instrument. These flags are described in the next section.
- The general syntax of the am instrument command is:
+ The general syntax of the am instrument command is:
am instrument [flags] <test_package>/<runner_class>
@@ -391,11 +395,11 @@ $ adb shell am instrument -w <test_package_name>/<runner_class>
<test_package>
- The Android package name of the test application.
+ The Android package name of the test package.
The value of the package attribute of the manifest
- element in the test application's manifest file.
+ element in the test package's manifest file.
@@ -411,7 +415,7 @@ $ adb shell am instrument -w <test_package_name>/<runner_class>
-The flags for am instrument are described in the following table:
+ The flags for am instrument are described in the following table:
- Provides testing options , in the form of key-value pairs. The
+ Provides testing options as key-value pairs. The
am instrument tool passes these to the specified instrumentation class
via its onCreate() method. You can specify multiple occurrences of
- -e <test_options. The keys and values are described in the next table.
+ -e <test_options>. The keys and values are described in the
+ section am instrument options.
- The only instrumentation class that understands these key-value pairs is
- |
The am instrument tool passes testing options to
InstrumentationTestRunner or a subclass in the form of key-value pairs,
@@ -484,123 +489,127 @@ The flags for am instrument are described in the following table:
-e <key> <value>
- Where applicable, a <key> may have multiple values separated by a comma (,).
+ Some keys accept multiple values. You specify multiple values in a comma-separated list.
For example, this invocation of InstrumentationTestRunner provides multiple
values for the package key:
+
-$ adb shell am instrument -w -e package com.android.test.package1,com.android.test.package2 com.android.test/android.test.InstrumentationTestRunner +$ adb shell am instrument -w -e package com.android.test.package1,com.android.test.package2 \ +> com.android.test/android.test.InstrumentationTestRunner
The following table describes the key-value pairs and their result. Please review the Usage Notes following the table.
| Key | -Value | -Description | -
|---|---|---|
- package
- |
- - <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 application has a single Android package - name but may have several Java packages within it. - | -
class |
- <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. - | -|
func |
- true |
- - Runs all test classes that extend {@link android.test.InstrumentationTestCase}. - | -
unit |
- true |
- - Runs all test classes that do not extend either - {@link android.test.InstrumentationTestCase} or {@link android.test.PerformanceTestCase}. - | -
size |
- [small | medium | large]
- |
-
- Runs a test method annotated by size. The annotations are @SmallTest,
- @MediumTest, and @LargeTest.
- |
-
perf |
- true |
-
- Runs all test classes that implement {@link android.test.PerformanceTestCase}.
- When you use this option, also specify the -r flag for
- am instrument, so that the output is kept in raw format and not
- re-formatted as test results.
- |
-
debug |
- true |
- - Runs tests in debug mode. - | -
log |
- true |
-
- Loads and logs all specified tests, but does not run them. The test
- information appears in STDOUT. Use this to verify combinations of other filters
- and test specifications.
- |
-
emma |
- true |
-
- Runs an EMMA code coverage analysis and writes the output to /data//coverage.ec
- on the device. To override the file location, use the coverageFile key that
- is described in the following entry.
-
- Note: This option requires an EMMA-instrumented build of the test
- application, which you can generate with the |
-
coverageFile |
- <filename> |
-
- 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 emma key.
- |
-
| Key | +Value | +Description | +
+ package
+ |
+ + <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 |
+ <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. + | +|
func |
+ true |
+ + Runs all test classes that extend {@link android.test.InstrumentationTestCase}. + | +
unit |
+ true |
+ + Runs all test classes that do not extend either + {@link android.test.InstrumentationTestCase} or + {@link android.test.PerformanceTestCase}. + | +
size |
+
+ [small | medium | large]
+ |
+
+ Runs a test method annotated by size. The annotations are @SmallTest,
+ @MediumTest, and @LargeTest.
+ |
+
perf |
+ true |
+
+ Runs all test classes that implement {@link android.test.PerformanceTestCase}.
+ When you use this option, also specify the -r flag for
+ am instrument, so that the output is kept in raw format and not
+ re-formatted as test results.
+ |
+
debug |
+ true |
+ + Runs tests in debug mode. + | +
log |
+ true |
+
+ Loads and logs all specified tests, but does not run them. The test
+ information appears in STDOUT. Use this to verify combinations of other
+ filters and test specifications.
+ |
+
emma |
+ true |
+
+ Runs an EMMA code coverage analysis and writes the output to
+ /data//coverage.ec on the device. To override the file location, use the
+ coverageFile key that is described in the following entry.
+
+ Note: This option requires an EMMA-instrumented build of the test
+ application, which you can generate with the |
+
coverageFile |
+ <filename> |
+
+ 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 emma key.
+ |
+
-e Flag Usage Notes
func key and unit key are mutually exclusive.
-Here are some examples of using am instrument to run tests. They are based on
-the following structure:
am instrument to run tests.
+They are based on the following structure:
com.android.demo.app.tests
+ The test package has the Android package name com.android.demo.app.tests
- To run all of the test classes in the test application, enter: + To run all of the test classes in the test package, enter:
$ adb shell am instrument -w com.android.demo.app.tests/android.test.InstrumentationTestRunner-
To run all of the tests in the class UnitTests, enter:
$ adb shell am instrument -w \ --e class com.android.demo.app.tests.UnitTests \ -com.android.demo.app.tests/android.test.InstrumentationTestRunner +> -e class com.android.demo.app.tests.UnitTests \ +> com.android.demo.app.tests/android.test.InstrumentationTestRunner
am instrument gets the value of the -e flag, detects the
class keyword, and runs all the methods in the UnitTests class.
- To run all of the tests in UnitTests, and the testCamera method in
- FunctionTests, enter:
+ To run all of the tests in UnitTests, and the testCamera method in
+ FunctionTests, enter:
$ adb shell am instrument -w \ --e class com.android.demo.app.tests.UnitTests,com.android.demo.app.tests.FunctionTests#testCamera \ -com.android.demo.app.tests/android.test.InstrumentationTestRunner +> -e class com.android.demo.app.tests.UnitTests,com.android.demo.app.tests.FunctionTests#testCamera \ +> com.android.demo.app.tests/android.test.InstrumentationTestRunner
You can find more examples of the command in the documentation for diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs index 35ce17e26eaea..9793748e8ce6e 100644 --- a/docs/html/guide/guide_toc.cs +++ b/docs/html/guide/guide_toc.cs @@ -254,9 +254,30 @@
+ Activity testing is particularly dependent on the the Android instrumentation framework. + Unlike other components, activities have a complex lifecycle based on callback methods; these + can't be invoked directly except by instrumentation. Also, the only way to send events to the + user interface from a program is through instrumentation. +
++ This document describes how to test activities using instrumentation and other test + facilities. The document assumes you have already read + Testing Fundamentals, + the introduction to the Android testing and instrumentation framework. +
++ The activity testing API base class is {@link android.test.InstrumentationTestCase}, + which provides instrumentation to the test case subclasses you use for Activities. +
++ For activity testing, this base class provides these functions: +
++ The activity testing classes also provide the JUnit framework by extending + {@link junit.framework.TestCase} and {@link junit.framework.Assert}. +
+
+ The two main testing subclasses are {@link android.test.ActivityInstrumentationTestCase2} and
+ {@link android.test.ActivityUnitTestCase}. To test an Activity that is launched in a mode
+ other than standard, you use {@link android.test.SingleLaunchActivityTestCase}.
+
+ The {@link android.test.ActivityInstrumentationTestCase2} test case class is designed to do + functional testing of one or more Activities in an application, using a normal system + infrastructure. It runs the Activities in a normal instance of the application under test, + using a standard system Context. It allows you to send mock Intents to the activity under + test, so you can use it to test an activity that responds to multiple types of intents, or + an activity that expects a certain type of data in the intent, or both. Notice, though, that it + does not allow mock Contexts or Applications, so you can not isolate the test from the rest of + a production system. +
++ The {@link android.test.ActivityUnitTestCase} test case class tests a single activity in + isolation. Before you start the activity, you can inject a mock Context or Application, or both. + You use it to run activity tests in isolation, and to do unit testing of methods + that do not interact with Android. You can not send mock Intents to the activity under test, + although you can call + {@link android.app.Activity#startActivity(Intent) Activity.startActivity(Intent)} and then + look at arguments that were received. +
++ The {@link android.test.SingleLaunchActivityTestCase} class is a convenience class for + testing a single activity in an environment that doesn't change from test to test. + It invokes {@link junit.framework.TestCase#setUp() setUp()} and + {@link junit.framework.TestCase#tearDown() tearDown()} only once, instead of once per + method call. It does not allow you to inject any mock objects. +
+
+ This test case is useful for testing an activity that runs in a mode other than
+ standard. It ensures that the test fixture is not reset between tests. You
+ can then test that the activity handles multiple calls correctly.
+
+ This section contains notes about the use of the mock objects defined in + {@link android.test.mock} with activity tests. +
+
+ The mock object {@link android.test.mock.MockApplication} is only available for activity
+ testing if you use the {@link android.test.ActivityUnitTestCase} test case class.
+ By default, ActivityUnitTestCase, creates a hidden MockApplication
+ object that is used as the application under test. You can inject your own object using
+ {@link android.test.ActivityUnitTestCase#setApplication(Application) setApplication()}.
+
+ {@link android.test.ViewAsserts} defines assertions for Views. You use it to verify the + alignment and position of View objects, and to look at the state of ViewGroup objects. +
+onCreate() or
+ onClick(). For example, an activity should respond to pause or destroy events
+ by saving its state. Remember that even a change in screen orientation causes the current
+ activity to be destroyed, so you should test that accidental device movements don't
+ accidentally lose the application state.
+ + To learn how to set up and run tests in Eclipse, please refer to Testing in + Eclipse, with ADT. If you're not working in Eclipse, refer to Testing in Other + IDEs. +
++ If you want a step-by-step introduction to testing activities, try one of the + testing tutorials: +
++ The following sections have tips for testing the UI of your Android application, specifically + to help you handle actions that run in the UI thread, touch screen and keyboard events, and home + screen unlock during testing. +
+
+ An application's activities run on the application's UI thread. Once the
+ UI is instantiated, for example in the activity's onCreate() method, then all
+ interactions with the UI must run in the UI thread. When you run the application normally, it
+ has access to the thread and does not have to do anything special.
+
+ This changes when you run tests against the application. With instrumentation-based classes,
+ you can invoke methods against the UI of the application under test. The other test classes
+ don't allow this. To run an entire test method on the UI thread, you can annotate the thread
+ with @UIThreadTest. Notice that this will run all of the method statements
+ on the UI thread. Methods that do not interact with the UI are not allowed; for example, you
+ can't invoke Instrumentation.waitForIdleSync().
+
+ To run a subset of a test method on the UI thread, create an anonymous class of type
+ Runnable, put the statements you want in the run() method, and
+ instantiate a new instance of the class as a parameter to the method
+ appActivity.runOnUiThread(), where appActivity is
+ the instance of the application you are testing.
+
+ For example, this code instantiates an activity to test, requests focus (a UI action) for the
+ Spinner displayed by the activity, and then sends a key to it. Notice that the calls to
+ waitForIdleSync and sendKeys aren't allowed to run on the UI thread:
+
+ private MyActivity mActivity; // MyActivity is the class name of the app under test
+ private Spinner mSpinner;
+
+ ...
+
+ protected void setUp() throws Exception {
+ super.setUp();
+ mInstrumentation = getInstrumentation();
+
+ mActivity = getActivity(); // get a references to the app under test
+
+ /*
+ * Get a reference to the main widget of the app under test, a Spinner
+ */
+ mSpinner = (Spinner) mActivity.findViewById(com.android.demo.myactivity.R.id.Spinner01);
+
+ ...
+
+ public void aTest() {
+ /*
+ * request focus for the Spinner, so that the test can send key events to it
+ * This request must be run on the UI thread. To do this, use the runOnUiThread method
+ * and pass it a Runnable that contains a call to requestFocus on the Spinner.
+ */
+ mActivity.runOnUiThread(new Runnable() {
+ public void run() {
+ mSpinner.requestFocus();
+ }
+ });
+
+ mInstrumentation.waitForIdleSync();
+
+ this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);
+
+
++ To control the emulator or a device with key events you send from your tests, you must turn off + touch mode. If you do not do this, the key events are ignored. +
+
+ To turn off touch mode, you invoke
+ ActivityInstrumentationTestCase2.setActivityTouchMode(false)
+ before you call getActivity() to start the activity. You must invoke the
+ method in a test method that is not running on the UI thread. For this reason, you
+ can't invoke the touch mode method from a test method that is annotated with
+ @UIThread. Instead, invoke the touch mode method from setUp().
+
+ You may find that UI tests don't work if the emulator's or device's home screen is disabled with
+ the keyguard pattern. This is because the application under test can't receive key events sent
+ by sendKeys(). The best way to avoid this is to start your emulator or device
+ first and then disable the keyguard for the home screen.
+
+ You can also explicitly disable the keyguard. To do this,
+ you need to add a permission in the manifest file (AndroidManifest.xml) and
+ then disable the keyguard in your application under test. Note, though, that you either have to
+ remove this before you publish your application, or you have to disable it with code in
+ the published application.
+
+ To add the the permission, add the element
+ <uses-permission android:name="android.permission.DISABLE_KEYGUARD"/>
+ as a child of the <manifest> element. To disable the KeyGuard, add the
+ following code to the onCreate() method of activities you intend to test:
+
+ mKeyGuardManager = (KeyguardManager) getSystemService(KEYGUARD_SERVICE);
+ mLock = mKeyGuardManager.newKeyguardLock("activity_classname");
+ mLock.disableKeyguard();
+
+where activity_classname is the class name of the activity.
+ This section lists some of the common test failures you may encounter in UI testing, and their + causes: +
+WrongThreadExceptionProblem:
+ For a failed test, the Failure Trace contains the following error message: +
+ android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created
+ a view hierarchy can touch its views.
+
+ Probable Cause:
+ This error is common if you tried to send UI events to the UI thread from outside the UI + thread. This commonly happens if you send UI events from the test application, but you don't + use the@UIThread annotation or the runOnUiThread() method. The
+ test method tried to interact with the UI outside the UI thread.
+ Suggested Resolution:
+ Run the interaction on the UI thread. Use a test class that provides instrumentation. See + the previous section Testing on the UI Thread + for more details. +java.lang.RuntimeExceptionProblem:
+ For a failed test, the Failure Trace contains the following error message: +
+ java.lang.RuntimeException: This method can not be called from the main application thread
+
+ Probable Cause:
+ This error is common if your test method is annotated with@UiThreadTest but
+ then tries to do something outside the UI thread or tries to invoke
+ runOnUiThread().
+ Suggested Resolution:
+ Remove the@UiThreadTest annotation, remove the runOnUiThread()
+ call, or re-factor your tests.
+ + Content providers, which store and retrieve data and make it accessible across applications, + are a key part of the Android API. As an application developer you're allowed to provide your + own public providers for use by other applications. If you do, then you should test them + using the API you publish. +
++ This document describes how to test public content providers, although the information is + also applicable to providers that you keep private to your own application. If you aren't + familiar with content providers or the Android testing framework, please read + Content Providers, + the guide to developing content providers, and + Testing Fundamentals, + the introduction to the Android testing and instrumentation framework. +
++ In Android, content providers are viewed externally as data APIs that provide + tables of data, with their internals hidden from view. A content provider may have many + public constants, but it usually has few if any public methods and no public variables. + This suggests that you should write your tests based only on the provider's public members. + A content provider that is designed like this is offering a contract between itself and its + users. +
++ The base test case class for content providers, + {@link android.test.ProviderTestCase2}, allows you to test your content provider in an + isolated environment. Android mock objects such as {@link android.test.IsolatedContext} and + {@link android.test.mock.MockContentResolver} also help provide an isolated test environment. +
++ As with other Android tests, provider test packages are run under the control of the test + runner {@link android.test.InstrumentationTestRunner}. The section + + Running Tests With InstrumentationTestRunner describes the test runner in + more detail. The topic + Testing in Eclipse, with ADT shows you how to run a test package in Eclipse, and the + topic + Testing in Other IDEs + shows you how to run a test package from the command line. +
++ The main focus of the provider testing API is to provide an isolated testing environment. This + ensures that tests always run against data dependencies set explicitly in the test case. It + also prevents tests from modifying actual user data. For example, you want to avoid writing + a test that fails because there was data left over from a previous test, and you want to + avoid adding or deleting contact information in a actual provider. +
++ The test case class and mock object classes for provider testing set up this isolated testing + environment for you. +
++ You test a provider with a subclass of {@link android.test.ProviderTestCase2}. This base class + extends {@link android.test.AndroidTestCase}, so it provides the JUnit testing framework as well + as Android-specific methods for testing application permissions. The most important + feature of this class is its initialization, which creates the isolated test environment. +
++ The initialization is done in the constructor for {@link android.test.ProviderTestCase2}, which + subclasses call in their own constructors. The {@link android.test.ProviderTestCase2} + constructor creates an {@link android.test.IsolatedContext} object that allows file and + database operations but stubs out other interactions with the Android system. + The file and database operations themselves take place in a directory that is local to the + device or emulator and has a special prefix. +
++ The constructor then creates a {@link android.test.mock.MockContentResolver} to use as the + resolver for the test. The {@link android.test.mock.MockContentResolver} class is described in + detail in the section + Mock object classes. +
++ Lastly, the constructor creates an instance of the provider under test. This is a normal + {@link android.content.ContentProvider} object, but it takes all of its environment information + from the {@link android.test.IsolatedContext}, so it is restricted to + working in the isolated test environment. All of the tests done in the test case class run + against this isolated object. +
++ {@link android.test.ProviderTestCase2} uses {@link android.test.IsolatedContext} and + {@link android.test.mock.MockContentResolver}, which are standard mock object classes. To + learn more about them, please read + + Testing Fundamentals. +
++ The topic What To Test + lists general considerations for testing Android components. + Here are some specific guidelines for testing content providers. +
++ To learn how to set up and run tests in Eclipse, please refer to Testing in + Eclipse, with ADT. If you're not working in Eclipse, refer to Testing in Other + IDEs. +
++ If you want a step-by-step introduction to testing activities, try one of the + testing tutorials: +
++ The Android development environment includes an integrated testing framework that helps you + test all aspects of your application. +
++ To start learning how to use the framework to create tests for your applications, please + read the topic + Testing Fundamentals. +
++ Android provides a testing framework for Service objects that can run them in + isolation and provides mock objects. The test case class for Service objects is + {@link android.test.ServiceTestCase}. Since the Service class assumes that it is separate + from its clients, you can test a Service object without using instrumentation. +
++ This document describes techniques for testing Service objects. If you aren't familiar with the + Service class, please read + Application Fundamentals. If you aren't familiar with Android testing, please read + Testing Fundamentals, + the introduction to the Android testing and instrumentation framework. +
++ When you design a Service, you should consider how your tests can examine the various states + of the Service lifecycle. If the lifecycle methods that start up your Service, such as + {@link android.app.Service#onCreate() onCreate()} or + {@link android.app.Service#onStartCommand(Intent, int, int) onStartCommand()} do not normally + set a global variable to indicate that they were successful, you may want to provide such a + variable for testing purposes. +
++ Most other testing is facilitated by the methods in the {@link android.test.ServiceTestCase} + test case class. For example, the {@link android.test.ServiceTestCase#getService()} method + returns a handle to the Service under test, which you can test to confirm that the Service is + running even at the end of your tests. +
++ {@link android.test.ServiceTestCase} extends the JUnit {@link junit.framework.TestCase} class + with with methods for testing application permissions and for controlling the application and + Service under test. It also provides mock application and Context objects that isolate your + test from the rest of the system. +
++ {@link android.test.ServiceTestCase} defers initialization of the test environment until you + call {@link android.test.ServiceTestCase#startService(Intent) ServiceTestCase.startService()} or + {@link android.test.ServiceTestCase#bindService(Intent) ServiceTestCase.bindService()}. This + allows you to set up your test environment, particularly your mock objects, before the Service + is started. +
+
+ Notice that the parameters to ServiceTestCase.bindService()are different from
+ those for Service.bindService(). For the ServiceTestCase version,
+ you only provide an Intent. Instead of returning a boolean,
+ ServiceTestCase.bindService() returns an object that subclasses
+ {@link android.os.IBinder}.
+
+ The {@link android.test.ServiceTestCase#setUp()} method for {@link android.test.ServiceTestCase}
+ is called before each test. It sets up the test fixture by making a copy of the current system
+ Context before any test methods touch it. You can retrieve this Context by calling
+ {@link android.test.ServiceTestCase#getSystemContext()}. If you override this method, you must
+ call super.setUp() as the first statement in the override.
+
+ The methods {@link android.test.ServiceTestCase#setApplication(Application) setApplication()} + and {@link android.test.AndroidTestCase#setContext(Context)} setContext()} allow you to set + a mock Context or mock Application (or both) for the Service, before you start it. These mock + objects are described in Mock object classes. +
++ By default, {@link android.test.ServiceTestCase} runs the test method + {@link android.test.AndroidTestCase#testAndroidTestCaseSetupProperly()}, which asserts that + the base test case class successfully set up a Context before running. +
+
+ ServiceTestCase assumes that you will use a mock Context or mock Application
+ (or both) for the test environment. These objects isolate the test environment from the
+ rest of the system. If you don't provide your own instances of these objects before you
+ start the Service, then {@link android.test.ServiceTestCase} will create its own internal
+ instances and inject them into the Service. You can override this behavior by creating and
+ injecting your own instances before starting the Service
+
+ To inject a mock Application object into the Service under test, first create a subclass of
+ {@link android.test.mock.MockApplication}. MockApplication is a subclass of
+ {@link android.app.Application} in which all the methods throw an Exception, so to use it
+ effectively you subclass it and override the methods you need. You then inject it into the
+ Service with the
+ {@link android.test.ServiceTestCase#setApplication(Application) setApplication()} method.
+ This mock object allows you to control the application values that the Service sees, and
+ isolates it from the real system. In addition, any hidden dependencies your Service has on
+ its application reveal themselves as exceptions when you run the test.
+
+ You inject a mock Context into the Service under test with the + {@link android.test.AndroidTestCase#setContext(Context) setContext()} method. The mock + Context classes you can use are described in more detail in + + Testing Fundamentals. +
++ The topic What To Test + lists general considerations for testing Android components. + Here are some specific guidelines for testing a Service: +
+Context.startService(). Only the first call triggers
+ Service.onCreate(), but all calls trigger a call to
+ Service.onStartCommand().
+
+ In addition, remember that startService() calls don't
+ nest, so a single call to Context.stopService() or
+ Service.stopSelf() (but not stopSelf(int))
+ will stop the Service. You should test that your Service stops at the correct point.
+
Android includes a powerful set of testing tools that extend the -industry-standard JUnit test framework with features specific to the Android -environment. Although you can test an Android application with JUnit, the -Android tools allow you to write much more sophisticated tests for every aspect -of your application, both at the unit and framework levels.
- -Key features of the Android testing environment include:
- -This document is an overview of the Android testing environment and the way -you use it. The document assumes you have a basic knowledge of Android -application programming and JUnit testing methodology.
- -At the heart of the Android testing environment is an instrumentation -framework that your test application uses to precisely control the application -under test. With instrumentation, you can set up mock system objects such as -Contexts before the main application starts, control your application at various -points of its lifecycle, send UI events to the application, and examine the -application's state during its execution. The instrumentation framework -accomplishes this by running both the main application and the test application -in the same process.
- -Your test application is linked to the application under test by means of an
-
- <instrumentation> element in the test application's manifest file.
- The attributes of the element specify the package name of the application under test and also
- tell Android how to run the test application. Instrumentation is described in more detail
- in the section Instrumentation Test Runner.
-
The following diagram summarizes the Android testing environment:
- -
-
- In Android, test applications are themselves Android applications, so you
- write them in much the same way as the application you are testing. The SDK
- tools help you create a main application project and its test project at the same
- time. You can run Android tests within Eclipse with ADT or from the command
- line. Eclipse with ADT provides an extensive set of tools for creating tests,
- running them, and viewing their results. You can also use the adb
- tool to run tests, or use a built-in Ant target.
+ The Android testing framework, an integral part of the development environment,
+ provides an architecture and powerful tools that help you test every aspect of your application
+ at every level from unit to framework.
+
+ The testing framework has these key features: +
++ This document describes the fundamentals of the Android testing framework, including the + structure of tests, the APIs that you use to develop tests, and the tools that you use to run + tests and view results. The document assumes you have a basic knowledge of Android application + programming and JUnit testing methodology. +
++ The following diagram summarizes the testing framework: +
+
+
++ Android's build and test tools assume that test projects are organized into a standard + structure of tests, test case classes, test packages, and test projects. +
++ Android testing is based on JUnit. In general, a JUnit test is a method whose + statements test a part of the application under test. You organize test methods into classes + called test cases (or test suites). Each test is an isolated test of an individual module in + the application under test. Each class is a container for related test methods, although it + often provides helper methods as well. +
++ In JUnit, you build one or more test source files into a class file. Similarly, in Android you + use the SDK's build tools to build one or more test source files into class files in an + Android test package. In JUnit, you use a test runner to execute test classes. In Android, you + use test tools to load the test package and the application under test, and the tools then + execute an Android-specific test runner. +
++ Tests, like Android applications, are organized into projects. +
++ A test project is a directory or Eclipse project in which you create the source code, manifest + file, and other files for a test package. The Android SDK contains tools for Eclipse with ADT + and for the command line that create and update test projects for you. The tools create the + directories you use for source code and resources and the manifest file for the test package. + The command-line tools also create the Ant build files you need. +
++ You should always use Android tools to create a test project. Among other benefits, + the tools: +
+InstrumentationTestRunner (or a subclass) to run JUnit tests.
+ com.mydomain.myapp, then the
+ Android tools set the test package name to com.mydomain.myapp.test. This
+ helps you identify their relationship, while preventing conflicts within the system.
+
+ You can create a test project anywhere in your file system, but the best approach is to
+ add the test project so that its root directory tests/ is at the same level
+ as the src/ directory of the main application's project. This helps you find the
+ tests associated with an application. For example, if your application project's root directory
+ is MyProject, then you should use the following directory structure:
+
+ MyProject/ + AndroidManifest.xml + res/ + ... (resources for main application) + src/ + ... (source code for main application) ... + tests/ + AndroidManifest.xml + res/ + ... (resources for tests) + src/ + ... (source code for tests) ++
+ The Android testing API is based on the JUnit API and extended with a instrumentation + framework and Android-specific testing classes. +
+
+ You can use the JUnit {@link junit.framework.TestCase TestCase} class to do unit testing on
+ a plain Java object. TestCase is also the base class for
+ {@link android.test.AndroidTestCase}, which you can use to test Android-dependent objects.
+ Besides providing the JUnit framework, AndroidTestCase offers Android-specific setup,
+ teardown, and helper methods.
+
+ You use the JUnit {@link junit.framework.Assert} class to display test results. + The assert methods compare values you expect from a test to the actual results and + throw an exception if the comparison fails. Android also provides a class of assertions that + extend the possible types of comparisons, and another class of assertions for testing the UI. + These are described in more detail in the section + Assertion classes +
++ To learn more about JUnit, you can read the documentation on the + junit.org home page. + Note that the Android testing API supports JUnit 3 code style, but not JUnit 4. Also, you must + use Android's instrumented test runner {@link android.test.InstrumentationTestRunner} to run + your test case classes. This test runner is described in the + section Running Tests. +
++ Android instrumentation is a set of control methods or "hooks" in the Android system. These hooks + control an Android component independently of its normal lifecycle. They also control how + Android loads applications. +
+
+ Normally, an Android component runs in a lifecycle determined by the system. For example, an
+ Activity object's lifecycle starts when the Activity is activated by an Intent. The object's
+ onCreate() method is called, followed by onResume(). When the user
+ starts another application, the onPause() method is called. If the Activity
+ code calls the finish() method, the onDestroy() method is called.
+ The Android framework API does not provide a way for your code to invoke these callback
+ methods directly, but you can do so using instrumentation.
+
+ Also, the system runs all the components of an application into the same + process. You can allow some components, such as content providers, to run in a separate process, + but you can't force an application to run in the same process as another application that is + already running. +
++ With Android instrumentation, though, you can invoke callback methods in your test code. + This allows you to run through the lifecycle of a component step by step, as if you were + debugging the component. The following test code snippet demonstrates how to use this to + test that an Activity saves and restores its state: +
+ ++ // Start the main activity of the application under test + mActivity = getActivity(); + + // Get a handle to the Activity object's main UI widget, a Spinner + mSpinner = (Spinner)mActivity.findViewById(com.android.example.spinner.R.id.Spinner01); + + // Set the Spinner to a known position + mActivity.setSpinnerPosition(TEST_STATE_DESTROY_POSITION); + + // Stop the activity - The onDestroy() method should save the state of the Spinner + mActivity.finish(); + + // Re-start the Activity - the onResume() method should restore the state of the Spinner + mActivity = getActivity(); + + // Get the Spinner's current position + int currentPosition = mActivity.getSpinnerPosition(); + + // Assert that the current position is the same as the starting position + assertEquals(TEST_STATE_DESTROY_POSITION, currentPosition); ++
+ The key method used here is + {@link android.test.ActivityInstrumentationTestCase2#getActivity()}, which is a + part of the instrumentation API. The Activity under test is not started until you call this + method. You can set up the test fixture in advance, and then call this method to start the + Activity. +
++ Also, instrumentation can load both a test package and the application under test into the + same process. Since the application components and their tests are in the same process, the + tests can invoke methods in the components, and modify and examine fields in the components. +
++ Android provides several test case classes that extend {@link junit.framework.TestCase} and + {@link junit.framework.Assert} with Android-specific setup, teardown, and helper methods. +
+
+ A useful general test case class, especially if you are
+ just starting out with Android testing, is {@link android.test.AndroidTestCase}. It extends
+ both {@link junit.framework.TestCase} and {@link junit.framework.Assert}. It provides the
+ JUnit-standard setUp() and tearDown() methods, as well as well as
+ all of JUnit's Assert methods. In addition, it provides methods for testing permissions, and a
+ method that guards against memory leaks by clearing out certain class references.
+
+ A key feature of the Android testing framework is its component-specific test case classes. + These address specific component testing needs with methods for fixture setup and + teardown and component lifecycle control. They also provide methods for setting up mock objects. + These classes are described in the component-specific testing topics: +
++ Android does not provide a separate test case class for BroadcastReceiver. Instead, test a + BroadcastReceiver by testing the component that sends it Intent objects, to verify that the + BroadcastReceiver responds correctly. +
++ You use the {@link android.test.ApplicationTestCase} test case class to test the setup and + teardown of {@link android.app.Application} objects. These objects maintain the global state of + information that applies to all the components in an application package. The test case can + be useful in verifying that the <application> element in the manifest file is correctly + set up. Note, however, that this test case does not allow you to control testing of the + components within your application package. +
++ If you want to use instrumentation methods in a test case class, you must use + {@link android.test.InstrumentationTestCase} or one of its subclasses. The + {@link android.app.Activity} test cases extend this base class with other functionality that + assists in Activity testing.
++ Because Android test case classes extend JUnit, you can use assertion methods to display the + results of tests. An assertion method compares an actual value returned by a test to an + expected value, and throws an AssertionException if the comparison test fails. Using assertions + is more convenient than doing logging, and provides better test performance. +
++ Besides the JUnit {@link junit.framework.Assert} class methods, the testing API also provides + the {@link android.test.MoreAsserts} and {@link android.test.ViewAsserts} classes: +
++ To facilitate dependency injection in testing, Android provides classes that create mock system + objects such as {@link android.content.Context} objects, + {@link android.content.ContentProvider} objects, {@link android.content.ContentResolver} + objects, and {@link android.app.Service} objects. Some test cases also provide mock + {@link android.content.Intent} objects. You use these mocks both to isolate tests + from the rest of the system and to facilitate dependency injection for testing. These classes + are found in the Java packages {@link android.test} and {@link android.test.mock}. +
++ Mock objects isolate tests from a running system by stubbing out or overriding + normal operations. For example, a {@link android.test.mock.MockContentResolver} + replaces the normal resolver framework with its own local framework, which is isolated + from the rest of the system. MockContentResolver also also stubs out the + {@link android.content.ContentResolver#notifyChange(Uri, ContentObserver, boolean)} method + so that observer objects outside the test environment are not accidentally triggered. +
++ Mock object classes also facilitate dependency injection by providing a subclass of the + normal object that is non-functional except for overrides you define. For example, the + {@link android.test.mock.MockResources} object provides a subclass of + {@link android.content.res.Resources} in which all the methods throw Exceptions when called. + To use it, you override only those methods that must provide information. +
++ These are the mock object classes available in Android: +
++ {@link android.test.mock.MockApplication}, {@link android.test.mock.MockContext}, + {@link android.test.mock.MockContentProvider}, {@link android.test.mock.MockCursor}, + {@link android.test.mock.MockDialogInterface}, {@link android.test.mock.MockPackageManager}, and + {@link android.test.mock.MockResources} provide a simple and useful mock strategy. They are + stubbed-out versions of the corresponding system object class, and all of their methods throw an + {@link java.lang.UnsupportedOperationException} exception if called. To use them, you override + the methods you need in order to provide mock dependencies. +
+Note: + {@link android.test.mock.MockContentProvider} + and {@link android.test.mock.MockCursor} are new as of API level 8. +
++ {@link android.test.mock.MockContentResolver} provides isolated testing of content providers by + masking out the normal system resolver framework. Instead of looking in the system to find a + content provider given an authority string, MockContentResolver uses its own internal table. You + must explicitly add providers to this table using + {@link android.test.mock.MockContentResolver#addProvider(String,ContentProvider)}. +
+
+ With this feature, you can associate a mock content provider with an authority. You can create
+ an instance of a real provider but use test data in it. You can even set the provider for an
+ authority to null. In effect, a MockContentResolver object isolates your test
+ from providers that contain real data. You can control the
+ function of the provider, and you can prevent your test from affecting real data.
+
+ Android provides two Context classes that are useful for testing: +
++ This class allows you to test an application's data operations without affecting real + data that may be present on the device. +
++ This object provides a quick way to set up an isolated area for data operations, + while keeping normal functionality for all other Context operations. +
++ Test cases are run by a test runner class that loads the test case class, set ups, + runs, and tears down each test. An Android test runner must also be instrumented, so that + the system utility for starting applications can control how the test package + loads test cases and the application under test. You tell the Android platform + which instrumented test runner to use by setting a value in the test package's manifest file. +
++ {@link android.test.InstrumentationTestRunner} is the primary Android test runner class. It + extends the JUnit test runner framework and is also instrumented. It can run any of the test + case classes provided by Android and supports all possible types of testing. +
+
+ You specify InstrumentationTestRunner or a subclass in your test package's
+ manifest file, in the
+ instrumentation element. Also, InstrumentationTestRunner code resides
+ in the shared library android.test.runner, which is not normally linked to
+ Android code. To include it, you must specify it in a
+ uses-library element.
+ You do not have to set up these elements yourself. Both Eclipse with ADT and the
+ android command-line tool construct them automatically and add them to your
+ test package's manifest file.
+
+ Note: If you use a test runner other than
+ InstrumentationTestRunner, you must change the <instrumentation>
+ element to point to the class you want to use.
+
+ To run {@link android.test.InstrumentationTestRunner}, you use internal system classes called by + Android tools. When you run a test in Eclipse with ADT, the classes are called automatically. + When you run a test from the command line, you run these classes with + Android Debug Bridge (adb). +
++ The system classes load and start the test package, kill any processes that + are running an instance of the application under test, and then load a new instance of the + application under test. They then pass control to + {@link android.test.InstrumentationTestRunner}, which runs + each test case class in the test package. You can also control which test cases and + methods are run using settings in Eclipse with ADT, or using flags with the command-line tools. +
++ Neither the system classes nor {@link android.test.InstrumentationTestRunner} run + the application under test. Instead, the test case does this directly. It either calls methods + in the application under test, or it calls its own methods that trigger lifecycle events in + the application under test. The application is under the complete control of the test case, + which allows it to set up the test environment (the test fixture) before running a test. This + is demonstrated in the previous code snippet that tests an + Activity that displays a Spinner widget. +
++ To learn more about running tests, please read the topics + + Testing in Eclipse, with ADT or + + Testing in Other IDes. +
+
+ The Android testing framework returns test results back to the tool that started the test.
+ If you run a test in Eclipse with ADT, the results are displayed in a new JUnit view pane. If
+ you run a test from the command line, the results are displayed in STDOUT. In
+ both cases, you see a test summary that displays the name of each test case and method that
+ was run. You also see all the assertion failures that occurred. These include pointers to the
+ line in the test code where the failure occurred. Assertion failures also list the expected
+ value and actual value.
+
+ The test results have a format that is specific to the IDE that you are using. The test + results format for Eclipse with ADT is described in + + Testing in Eclipse, with ADT. The test results format for tests run from the + command line is described in + + Testing in Other IDEs. +
++ The SDK provides two tools for functional-level application testing: +
++ In the test environment, you work with both Android application package names and + Java package identifiers. Both use the same naming format, but they represent substantially + different entities. You need to know the difference to set up your tests correctly. +
+
+ An Android package name is a unique system name for a .apk file, set by the
+ "android:package" attribute of the <manifest> element in the package's
+ manifest. The Android package name of your test package must be different from the
+ Android package name of the application under test. By default, Android tools create the
+ test package name by appending ".test" to the package name of the application under test.
+
+ The test package also uses an Android package name to target the application package it + tests. This is set in the "android:targetPackage" attribute of the + <instrumentation> element in the test package's manifest. +
++ A Java package identifier applies to a source file. This package name reflects the directory + path of the source file. It also affects the visibility of classes and members to each other. +
++ Android tools that create test projects set up an Android test package name for you. + From your input, the tools set up the test package name and the target package name for the + application under test. For these tools to work, the application project must already exist. +
+
+ By default, these tools set the Java package identifier for the test class to be the same
+ as the Android package identifier. You may want to change this if you want to expose
+ members in the application under test by giving them package visibility. If you do this,
+ change only the Java package identifier, not the Android package names, and change only the
+ test case source files. Do not change the Java package name of the generated
+ R.java class in your test package, because it will then conflict with the
+ R.java class in the application under test. Do not change the Android package name
+ of your test package to be the same as the application it tests, because then their names
+ will no longer be unique in the system.
+
+ The topic What To Test + describes the key functionality you should test in an Android application, and the key + situations that might affect that functionality. +
++ Most unit testing is specific to the Android component you are testing. + The topics Activity Testing, + + Content Provider Testing, and + Service Testing each have a section entitled "What To Test" that lists possible testing + areas. +
++ When possible, you should run these tests on an actual device. If this is not possible, you can + use the Android Emulator with + Android Virtual Devices configured for + the hardware, screens, and versions you want to test. +
+To learn how to set up and run tests in Eclipse, please refer to Testing in @@ -150,12 +627,10 @@ in the same process.
href="{@docRoot}guide/developing/testing/testing_otheride.html">Testing in Other IDEs. -If you want a step-by-step introduction to Android testing, try one of the - testing tutorials: + testing tutorials or sample test packages:
-- For writing tests and test applications in the Java programming language, Android provides a - testing API that is based in part on the JUnit test framework. Adding to that, Android includes - a powerful instrumentation framework that lets your tests access the state and runtime objects - of the application under tests. -
-- The sections below describe the major components of the testing API available in Android. -
-- Some of the classes in the testing API extend the JUnit {@link junit.framework.TestCase TestCase} - but do not use the instrumentation framework. These classes contain methods for accessing system - objects such as the Context of the application under test. With this Context, you can look at its - resources, files, databases, and so forth. The base class is {@link android.test.AndroidTestCase}, - but you usually use a subclass associated with a particular component. -
- The subclasses are: -
-- The API for testing activities extends the JUnit {@link junit.framework.TestCase TestCase} class - and also uses the instrumentation framework. With instrumentation, Android can automate UI - testing by sending events to the application under test, precisely control the start of an - activity, and monitor the state of the activity during its life cycle. -
-- The base class is {@link android.test.InstrumentationTestCase}. All of its subclasses have - the ability to send a keystroke or touch event to the UI of the application - under test. The subclasses can also inject a mock Intent. The subclasses are: -
-- Unlike the other instrumentation classes, this test class cannot inject a mock Intent. -
-
- Android also extends the JUnit {@link junit.framework.Assert} class that is the basis of
- assert() calls in tests. There are two extensions to this class,
- {@link android.test.MoreAsserts} and {@link android.test.ViewAsserts}:
-
MoreAsserts class contains more powerful assertions such as
- {@link android.test.MoreAsserts#assertContainsRegex} that does regular expression matching.
- - Android has convenience classes for creating mock system objects such as applications, contexts, - content resolvers, and resources. Android also provides methods in some test classes for - creating mock Intents. Use these mocks to facilitate dependency injection, since they are - easier to use than creating their real counterparts. These convenience classes are found in - {@link android.test} and {@link android.test.mock}. They are: -
-
- Android provides a custom class for running tests with instrumentation called called
- {@link android.test.InstrumentationTestRunner}. This class
- controls of the application under test, runs the test application and the main application in the
- same process, and routes test output to the appropriate place. Using instrumentation is key to the
- ability of InstrumentationTestRunner to control the entire test
- environment at runtime. Notice that you use this test runner even if your test class does not
- itself use instrumentation.
-
- When you run a test application, you first run a system utility called Activity Manager. Activity - Manager uses the instrumentation framework to start and control the test runner, which in turn - uses instrumentation to shut down any running instances of the main application, starts the test - application, and then starts the main application in the same process. This allows various - aspects of the test application to work directly with the main application. -
-
- If you are developing in Eclipse, the ADT plugin assists you in the setup of
- InstrumentationTestRunner or other test runners. The plugin UI prompts you to specify
- the test runner class to use, as well as the package name of the application under test.
- The plugin then adds an <instrumentation> element with appropriate attributes
- to the manifest file of the test application. Eclipse with ADT automatically starts a test
- application under the control of Activity Manager using instrumentation, and redirects the test
- output to the Eclipse window's JUnit view.
-
- If you prefer working from the command line, you can use Ant and the android
- tool to help you set up your test projects. To run tests with instrumentation, you can access the
- Activity Manager through the Android Debug
- Bridge (adb) tool and the output is directed to STDOUT.
-
- The tests for an Android application are contained in a test application, which itself is an - Android application. A test application resides in a separate Android project that has the - same files and directories as a regular Android application. The test project is linked to the - project of the application it tests (known as the application under test) by its manifest file. -
-- Each test application contains one or more test case classes based on an Android class for a - particular type of component. The test case class contains methods that define tests on some - part of the application under test. When you run the test application, Android - starts it, loads the application under test into the same process, and then invokes each method - in the test case class. -
-- The tools and procedures you use with testing depend on the development environment you are - using. If you use Eclipse, then the ADT plug in for Eclipse provides tools that allow you to - develop and run tests entirely within Eclipse. This is documented in the topic - - Testing in Eclipse, with ADT. If you use another development environment, then you use - Android's command-line tools, as documented in the topic - Testing in Other IDEs. -
-- To start testing an Android application, you create a test project for it using Android tools. - The tools create the project directory and the files and subdirectories needed. - The tools also create a manifest file that links the application in the test project to the - application under test. The procedure for creating a test project in Eclipse with ADT is - documented in - Testing in Eclipse, with ADT. The procedure for creating a test project for use with - development tools other than Eclipse is documented in - Testing in Other IDEs. -
-- A test application contains one or more test case classes that extend an Android test case - class. You choose a test case class based on the type of Android component you are testing and - the tests you are doing. A test application can test different components, but each test case - class is designed to test a single type of component. The Android test case classes are - described in the section The Testing API. -
-- Some Android components have more than one associated test case class. In this case, you choose - among the available classes based on the type of tests you want to do. For activities, for - example, you have the choice of either {@link android.test.ActivityInstrumentationTestCase2} or - {@link android.test.ActivityUnitTestCase}. -
- ActivityInstrumentationTestCase2 is designed to do functional testing, so it tests
- activities in a normal system infrastructure. You can inject mocked Intents, but not
- mocked Contexts. In general, you can't mock dependencies for the activity under test.
-
- In comparison, ActivityUnitTestCase is designed for unit testing, so it tests
- activities in an isolated system infrastructure. You can inject mocked or wrappered
- dependencies for the activity under test, particularly mocked Contexts. On the other hand,
- when you use this test case class the activity under test runs in isolation and can't interact
- with other activities.
-
- As a rule of thumb, if you wanted to test an activity's interaction with the rest of Android,
- you would use ActivityInstrumentationTestCase2. If you wanted to do regression
- testing on an activity, you would use ActivityUnitTestCase.
-
- Each test case class provides methods that you use to set up the test environment and control
- the application under test. For example, all test case classes provide the JUnit
- {@link junit.framework.TestCase#setUp() setUp()} method that you can override to set up
- fixtures. In addition, you add methods to the class to define individual tests. Each method you
- add is run once each time you run the test application. If you override the setUp()
- method, it runs before each of your methods. Similarly, the JUnit
- {@link junit.framework.TestCase#tearDown() tearDown()} method is run once after each of
- your methods.
-
- The test case classes give you substantial control over starting and stopping components. For
- this reason, you have to specifically tell Android to start a component before you run tests
- against it. For example, you use the
- {@link android.test.ActivityInstrumentationTestCase2#getActivity()} method to start the activity
- under test. You can call this method once during the entire test case, or once for each test
- method. You can even destroy the activity under test by calling its
- {@link android.app.Activity#finish()} method and then restart it with
- getActivity() within a single test method.
-
- To run your tests, you build your test project and then run the test application using the - system utility Activity Manager with instrumentation. You provide to Activity Manager the name - of the test runner (usually {@link android.test.InstrumentationTestRunner}) you specified for - your application; the name includes both your test application's package name and the test - runner class name. Activity Manager loads and starts your test application, kills any instances - of the application under test, loads an instance of the application under test into the same - process as the test application, and then passes control to the first test case class in your - test application. The test runner then takes control of the tests, running each of your test - methods against the application under test until all the methods in all the classes have been - run. -
-- If you run a test within Eclipse with ADT, the output appears in a new JUnit view pane. If you - run a test from the command line, the output goes to STDOUT. -
-- In addition to the functional areas you would normally test, here are some areas - of Android application testing that you should consider: -
-- When possible, you should run these tests on an actual device. If this is not possible, you can - use the Android Emulator with - Android Virtual Devices configured for - the hardware, screens, and versions you want to test. -
-- The following sections have tips for testing the UI of your Android application, specifically - to help you handle actions that run in the UI thread, touch screen and keyboard events, and home - screen unlock during testing. -
-
- An application's activities run on the application's UI thread. Once the
- UI is instantiated, for example in the activity's onCreate() method, then all
- interactions with the UI must run in the UI thread. When you run the application normally, it
- has access to the thread and does not have to do anything special.
-
- This changes when you run tests against the application. With instrumentation-based classes,
- you can invoke methods against the UI of the application under test. The other test classes
- don't allow this. To run an entire test method on the UI thread, you can annotate the thread
- with @UIThreadTest. Notice that this will run all of the method statements
- on the UI thread. Methods that do not interact with the UI are not allowed; for example, you
- can't invoke Instrumentation.waitForIdleSync().
-
- To run a subset of a test method on the UI thread, create an anonymous class of type
- Runnable, put the statements you want in the run() method, and
- instantiate a new instance of the class as a parameter to the method
- appActivity.runOnUiThread(), where appActivity is
- the instance of the app you are testing.
-
- For example, this code instantiates an activity to test, requests focus (a UI action) for the
- Spinner displayed by the activity, and then sends a key to it. Notice that the calls to
- waitForIdleSync and sendKeys aren't allowed to run on the UI thread:
-
- private MyActivity mActivity; // MyActivity is the class name of the app under test
- private Spinner mSpinner;
-
- ...
-
- protected void setUp() throws Exception {
- super.setUp();
- mInstrumentation = getInstrumentation();
-
- mActivity = getActivity(); // get a references to the app under test
-
- /*
- * Get a reference to the main widget of the app under test, a Spinner
- */
- mSpinner = (Spinner) mActivity.findViewById(com.android.demo.myactivity.R.id.Spinner01);
-
- ...
-
- public void aTest() {
- /*
- * request focus for the Spinner, so that the test can send key events to it
- * This request must be run on the UI thread. To do this, use the runOnUiThread method
- * and pass it a Runnable that contains a call to requestFocus on the Spinner.
- */
- mActivity.runOnUiThread(new Runnable() {
- public void run() {
- mSpinner.requestFocus();
- }
- });
-
- mInstrumentation.waitForIdleSync();
-
- this.sendKeys(KeyEvent.KEYCODE_DPAD_CENTER);
-
-
-- To control the emulator or a device with key events you send from your tests, you must turn off - touch mode. If you do not do this, the key events are ignored. -
-
- To turn off touch mode, you invoke
- ActivityInstrumentationTestCase2.setActivityTouchMode(false)
- before you call getActivity() to start the activity. You must invoke the
- method in a test method that is not running on the UI thread. For this reason, you
- can't invoke the touch mode method from a test method that is annotated with
- @UIThread. Instead, invoke the touch mode method from setUp().
-
- You may find that UI tests don't work if the emulator's or device's home screen is disabled with
- the keyguard pattern. This is because the application under test can't receive key events sent '
- by sendKeys(). The best way to avoid this is to start your emulator or device
- first and then disable the keyguard for the home screen.
-
- You can also explicitly disable the keyguard. To do this,
- you need to add a permission in the manifest file (AndroidManifest.xml) and
- then disable the keyguard in your application under test. Note, though, that you either have to
- remove this before you publish your application, or you have to disable it programmatically in
- the published app.
-
- To add the the permission, add the element
- <uses-permission android:name="android.permission.DISABLE_KEYGUARD"/>
- as a child of the <manifest> element. To disable the KeyGuard, add the
- following code to the onCreate() method of activities you intend to test:
-
- mKeyGuardManager = (KeyguardManager) getSystemService(KEYGUARD_SERVICE);
- mLock = mKeyGuardManager.newKeyguardLock("activity_classname");
- mLock.disableKeyguard();
-
-where activity_classname is the class name of the activity.
- This section lists some of the common test failures you may encounter in UI testing, and their - causes: -
-WrongThreadExceptionProblem:
- For a failed test, the Failure Trace contains the following error message: -
- android.view.ViewRoot$CalledFromWrongThreadException: Only the original thread that created
- a view hierarchy can touch its views.
-
- Probable Cause:
- This error is common if you tried to send UI events to the UI thread from outside the UI - thread. This commonly happens if you send UI events from the test application, but you don't - use the@UIThread annotation or the runOnUiThread() method. The
- test method tried to interact with the UI outside the UI thread.
- Suggested Resolution:
- Run the interaction on the UI thread. Use a test class that provides instrumentation. See - the previous section Testing on the UI Thread - for more details. -java.lang.RuntimeExceptionProblem:
- For a failed test, the Failure Trace contains the following error message: -
- java.lang.RuntimeException: This method can not be called from the main application thread
-
- Probable Cause:
- This error is common if your test method is annotated with@UiThreadTest but
- then tries to do something outside the UI thread or tries to invoke
- runOnUiThread().
- Suggested Resolution:
- Remove the@UiThreadTest annotation, remove the runOnUiThread()
- call, or re-factor your tests.
- + As you develop Android applications, knowing what to test is as important as knowing how to + test. This document lists some most common Android-related situations that you should consider + when you test, even at the unit test level. This is not an exhaustive list, and you consult the + documentation for the features that you use for more ideas. The + android-developers Google Groups + site is another resource for information about testing. +
++ The following sections are organized by behaviors or situations that you should test. Each + section contains a scenario that further illustrates the situation and the test or tests you + should do. +
++ For devices that support multiple orientations, Android detects a change in orientation when + the user turns the device so that the display is "landscape" (long edge is horizontal) instead + of "portrait" (long edge is vertical). +
++ When Android detects a change in orientation, its default behavior is to destroy and then + re-start the foreground Activity. You should consider testing the following: +
++ A situation that is more general than a change in orientation is a change in the device's + configuration, such as a change in the availability of a keyboard or a change in system + language. +
++ A change in configuration also triggers the default behavior of destroying and then restarting + the foreground Activity. Besides testing that the application maintains the UI and its + transaction state, you should also test that the application updates itself to respond + correctly to the new configuration. +
++ Mobile devices primarily run on battery power. A device has finite "battery budget", and when it + is gone, the device is useless until it is recharged. You need to write your application to + minimize battery usage, you need to test its battery performance, and you need to test the + methods that manage battery usage. +
++ Techniques for minimizing battery usage were presented at the 2010 Google I/O conference in the + presentation + + Coding for Life -- Battery Life, That Is. This presentation describes the impact on battery + life of various operations, and the ways you can design your application to minimize these + impacts. When you code your application to reduce battery usage, you also write the + appropriate unit tests. +
++ If your application depends on network access, SMS, Bluetooth, or GPS, then you should + test what happens when the resource or resources are not available. +
++ For example, if your application uses the network,it can notify the user if access is + unavailable, or disable network-related features, or do both. For GPS, it can switch to + IP-based location awareness. It can also wait for WiFi access before doing large data transfers, + since WiFi transfers maximize battery usage compared to transfers over 3G or EDGE. +
++ You can use the emulator to test network access and bandwidth. To learn more, please see + Network Speed Emulation. + To test GPS, you can use the emulator console and {@link android.location.LocationManager}. To + learn more about the emulator console, please see + + Using the Emulator Console. +
diff --git a/docs/html/images/testing/android_test_framework.png b/docs/html/images/testing/android_test_framework.png index 6f80530021d74..459975c06c124 100755 Binary files a/docs/html/images/testing/android_test_framework.png and b/docs/html/images/testing/android_test_framework.png differ diff --git a/docs/html/images/testing/test_framework.png b/docs/html/images/testing/test_framework.png new file mode 100644 index 0000000000000..fbc5fc2ad42b0 Binary files /dev/null and b/docs/html/images/testing/test_framework.png differ