diff --git a/docs/html/guide/developing/testing/index.jd b/docs/html/guide/developing/testing/index.jd new file mode 100644 index 0000000000000..ea61cc362d785 --- /dev/null +++ b/docs/html/guide/developing/testing/index.jd @@ -0,0 +1,37 @@ +page.title=Testing Overview +@jd:body + +
+ 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 + help you set up and run your tests within an emulator or the device you are targeting. + The documents listed below explain how to work with the tools in your development environment. +
++ If you aren't yet familiar with the Android testing framework, please read the topic + Testing and Instrumentation + before you get started. + For a step-by-step introduction to Android testing, try the Hello, Testing + tutorial, which introduces basic testing concepts and procedures. + For a more advanced tutorial, try Activity Testing, + which guides you through a more complex testing scenario. +
+android tool to create and manage test projects, the Ant build system
+ to compile them, and the adb tool to install and run them.
+ + 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. +
++ ADT provides several features that help you set up and manage your testing environment + effectively: +
+<instrumentation> element in the test application's manifest file.
+ + If you are not developing in Eclipse or you want to learn how to create and run tests from the + command line, see + Testing in Other IDEs. +
+
+ 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
+ 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
+ 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: +
++ +
++ 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. +
++ 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:
+
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.
+ 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. +
++ 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.
+
+ 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.
+
+ 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 +
++ 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.)
+
+ 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
+
Launching instrumentation Android.test.InstrumentationTestRunner on device device-id.Test run complete.+ 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 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 + test methods in that class, you click the left arrow to expand the line. You now see a + line for each test method in the class, and to its right the time it took to run. + If you double-click the method name, Eclipse opens the test class source in an editor view + pane and moves the focus to the first line of the test method. +
++ The lower pane is for stack traces. If you highlight a failed test in the upper pane, the + lower pane contains a stack trace for the test. If a line corresponds to a point in your + test code, you can double-click it to display the code in an editor view pane, with the + line highlighted. For a successful test, the lower pane is empty. +
diff --git a/docs/html/guide/developing/testing/testing_otheride.jd b/docs/html/guide/developing/testing/testing_otheride.jd new file mode 100644 index 0000000000000..2bdf4d0b0b70d --- /dev/null +++ b/docs/html/guide/developing/testing/testing_otheride.jd @@ -0,0 +1,683 @@ +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. +
++ 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.
+
+ 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: +
+| 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.
+ |
+
-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, android lists to STDOUT the names of the files
+ and directories it has created.
+
+ This creates a new test project with the appropriate directories and build files. The directory + structure and build file contents are identical to those in a regular Android application + project. They are described in detail in the topic + Developing In Other IDEs. +
+
+ The operation also creates an AndroidManifest.xml file with instrumentation
+ information. When you run the test, Android uses this information to load the application you
+ are testing and control it with instrumentation.
+
+ 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:
+
+$ cd ~/source +$ android create test-project -m ../HelloAndroid -n HelloAndroidTest -p HelloAndroidTest ++
+ This creates a directory called ~/src/HelloAndroidTest. In the new directory you
+ see the file AndroidManifest.xml. This file contains the following
+ instrumentation-related elements and attributes:
+
<application>: to contain the
+ <uses-library> element.
+ <uses-library android:name="android.test.runner":
+ specifies this testing application uses the android.test.runner library.
+ <instrumentation>: contains attributes that control Android
+ instrumentation. The attributes are:
+ android:name="android.test.InstrumentationTestRunner":
+ {@link android.test.InstrumentationTestRunner} runs test cases. It extends both
+ JUnit test case runner classes and Android instrumentation classes.
+ android:targetPackage="com.example.helloandroid": specifies
+ that the tests in HelloAndroidTest should be run against the application with the
+ Android package name com.example.helloandroid. This is the
+ package name of the Hello, World
+ tutorial application.
+ android:label="Tests for .HelloAndroid": specifies a
+ user-readable label for the instrumentation class. By default,
+ the android tool gives it the value "Tests for " plus
+ the name of the main Activity of the application under test.
+
+ You use the android tool when you need to change the path to the
+ project of the application under test. If you are changing an existing test project created in
+ Eclipse with ADT so that you can also build and run it from the command line, you must use the
+ "create" operation. See the section Creating a test project.
+
+ Note: If you change the Android package name of the application under test,
+ you must manually change the value of the <android:targetPackage>
+ attribute within the AndroidManifest.xml file of the test application.
+ Running android update test-project does not do this.
+
+ To update a test project with the android tool, enter:
+
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.
+ |
+
+ 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. + The 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. +
++ If you run your tests with {@link android.test.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:
+
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.
+ 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.
+
+ To learn more about creating test applications, see the topic Testing and Instrumentation, + 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 can use Ant to run all the tests in your test project, using the target
+ run-tests, which is created automatically when you create a test project with
+ the android tool.
+
+ This target re-builds your main project and test project if necessary, installs the test
+ application to the current AVD or device, and then runs all the test classes in the test
+ application. The results are directed to STDOUT.
+
+ 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.
+
+ 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 with am:
+
.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.
+ This operation starts an adb shell, then runs am instrument in it
+ 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
+ am instrument. These flags are described in the next section.
+
+ The general syntax of the am instrument command is:
+
+ am instrument [flags] <test_package>/<runner_class> ++
+ The main input parameters to am instrument are described in the following table:
+
| + Parameter + | ++ Value + | ++ Description + | +
|---|---|---|
+ <test_package>
+ |
+ + The Android package name of the test application. + | +
+ The value of the package attribute of the manifest
+ element in the test application's manifest file.
+ |
+
+ <runner_class>
+ |
+ + The class name of the instrumented test runner you are using. + | ++ This is usually {@link android.test.InstrumentationTestRunner}. + | +
+The flags for am instrument are described in the following table:
+
| + Flag + | ++ Value + | ++ Description + | +
|---|---|---|
+ -w
+ |
+ + (none) + | +
+ Forces am instrument to wait until the instrumentation terminates
+ before terminating itself. The net effect is to keep the shell open until the tests
+ have finished. This flag is not required, but if you do not use it, you will not
+ see the results of your tests.
+ |
+
+ -r
+ |
+ + (none) + | +
+ Outputs results in raw format. Use this flag when you want to collect
+ performance measurements, so that they are not formatted as test results. This flag is
+ designed for use with the flag -e perf true (documented in the section
+ Instrument options).
+ |
+
+ -e
+ |
+ + <test_options> + | +
+ Provides testing options , in the form of 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.
+
+ 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,
+ using the -e flag, with this syntax:
+
+ -e <key> <value> ++
+ Where applicable, a <key> may have multiple values separated by a comma (,).
+ 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 ++
+ 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.
+ |
+
-e Flag Usage Notes
+am instrument invokes
+ {@link android.test.InstrumentationTestRunner#onCreate(Bundle)}
+ with a {@link android.os.Bundle} containing the key-value pairs.
+ package key takes precedence over the class key. If you
+ specifiy a package, and then separately specify a class within that package, Android
+ will run all the tests in the package and ignore the class key.
+ 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:
com.android.demo.app.tests
+ UnitTests, which contains the methods
+ testPermissions and testSaveState.
+ FunctionTests, which contains the methods
+ testCamera, testXVGA, and testHardKeyboard.
+ IntegrationTests,
+ which contains the method testActivityProvider.
+ + To run all of the test classes in the test application, 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 ++
+ 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:
+
+$ 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 ++
+ You can find more examples of the command in the documentation for + {@link android.test.InstrumentationTestRunner}. +
diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs index 31d9f1aa328fb..22775017c0826 100644 --- a/docs/html/guide/guide_toc.cs +++ b/docs/html/guide/guide_toc.cs @@ -274,6 +274,25 @@{@code android:targetPackage}
The application that the Instrumentation object will run against.
An application is identified by the package name assigned in its manifest
@@ -62,4 +58,8 @@ file by the
In this document
@@ -72,70 +73,92 @@ page.title=Testing and Instrumentation
See Also
-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 at the framework level. -
--Key features of the Android testing environment include: -
+ +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. -
+ +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's manifest file links it to the application under test. The the <instrumentation> attribute in the manifest file points to the application under test - and also tells Android how to run the test application. This is described in more detail in the section Instrumentation Test Runner. -
--The following diagram summarizes the Android testing environment: -
+ +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.
-
- 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 Android testing, try one of the testing tutorials: -
-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.
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 Android testing, try one of the +testing tutorials:
+ +For writing tests and test applications in the Java programming language, Android provides a @@ -277,15 +300,15 @@ The following diagram summarizes the Android testing environment:
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. + 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. + 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.
diff --git a/docs/html/resources/tutorials/testing/helloandroid_test.jd b/docs/html/resources/tutorials/testing/helloandroid_test.jd index f06d5afcf7f94..b47c334b371df 100644 --- a/docs/html/resources/tutorials/testing/helloandroid_test.jd +++ b/docs/html/resources/tutorials/testing/helloandroid_test.jd @@ -86,7 +86,7 @@ page.title=Hello, Testing
If you aren't developing in Eclipse with ADT or you would like to run tests directly from the - command line, please see the topic Testing in Other IDEs + command line, please see the topic Testing in Other IDEs for instructions.