1 page.title=Testing In Other IDEs 2 @jd:body 3 4 <div id="qv-wrapper"> 5 <div id="qv"> 6 <h2>In this document</h2> 7 <ol> 8 <li> 9 <a href="#CreateTestProjectCommand">Working with Test Projects</a> 10 <ol> 11 <li> 12 <a href="#CreateTestProject">Creating a test project</a> 13 </li> 14 <li> 15 <a href="#UpdateTestProject">Updating a test project</a> 16 </li> 17 </ol> 18 </li> 19 <li> 20 <a href="#CreateTestApp">Creating a Test Application</a> 21 </li> 22 <li> 23 <a href="#RunTestsCommand">Running Tests</a> 24 <ol> 25 <li> 26 <a href="#RunTestsAnt">Quick build and run with Ant</a> 27 </li> 28 <li> 29 <a href="#RunTestsDevice">Running tests on a device or emulator</a> 30 </li> 31 </ol> 32 </li> 33 <li> 34 <a href="#AMSyntax">Using the Instrument Command</a> 35 <ol> 36 <li> 37 <a href="#AMOptionsSyntax">Instrument options</a> 38 </li> 39 <li> 40 <a href="#RunTestExamples">Instrument examples</a> 41 </li> 42 </ol> 43 </li> 44 45 </ol> 46 <h2>See Also</h2> 47 <ol> 48 <li> 49 <a 50 href="{@docRoot}guide/topics/testing/testing_android.html">Testing and Instrumentation</a> 51 </li> 52 <li> 53 <a href="{@docRoot}resources/tutorials/testing/activity_test.html">Activity Testing</a> 54 </li> 55 <li> 56 <a href="{@docRoot}guide/developing/tools/adb.html">Android Debug Bridge</a> 57 </li> 58 </ol> 59 </div> 60 </div> 61 <p> 62 This document describes how to create and run tests directly from the command line. 63 You can use the techniques described here if you are developing in an IDE other than Eclipse 64 or if you prefer to work from the command line. This document assumes that you already know how 65 to create a Android application in your programming environment. Before you start this 66 document, you should read the document <a 67 href="{@docRoot}guide/topics/testing/testing_android.html">Testing and Instrumentation</a>, 68 which provides an overview of Android testing. 69 </p> 70 <p> 71 If you are developing in Eclipse with ADT, you can set up and run your tests 72 directly in Eclipse. For more information, please read <a 73 href="{@docRoot}guide/developing/testing/testing_eclipse.html">Testing in Eclipse, with ADT</a>. 74 </p> 75 <h2 id="CreateTestProjectCommand">Working with Test Projects</h2> 76 <p> 77 You use the <code>android</code> tool to create test projects. 78 You also use <code>android</code> to convert existing test code into an Android test project, 79 or to add the <code>run-tests</code> Ant target to an existing Android test project. 80 These operations are described in more detail in the section <a 81 href="#UpdateTestProject">Updating a test project</a>. 82 The <code>run-tests</code> target is described in <a 83 href="#RunTestsAnt">Quick build and run with Ant</a>. 84 </p> 85 <h3 id="CreateTestProject">Creating a test project</h3> 86 <p> 87 To create a test project with the <code>android</code> tool, enter: 88 <pre>android create test-project -m <main_path> -n <project_name> -p <test_path></pre> 89 <p> 90 You must supply all the flags. The following table explains them in detail: 91 </p> 92 <table> 93 <tr> 94 <th>Flag</th> 95 <th>Value</th> 96 <th>Description</th> 97 <tr> 98 <td><code>-m, --main</code></td> 99 <td> 100 Path to the project of the application under test, relative to the test application 101 directory. 102 </td> 103 <td> 104 For example, if the application under test is in <code>source/HelloAndroid</code>, and you 105 want to create the test project in <code>source/HelloAndroidTest</code>, then the value of 106 <code>--main</code> should be <code>../HelloAndroid</code>. 107 </td> 108 <tr> 109 <td><code>-n, --name</code></td> 110 <td>Name that you want to give the test project.</td> 111 <td> </td> 112 </tr> 113 <tr> 114 <td><code>-p, --path</code></td> 115 <td>Directory in which you want to create the new test project.</td> 116 <td> 117 The <code>android</code> tool creates the test project files and directory structure in this 118 directory. If the directory does not exist, <code>android</code> creates it. 119 </td> 120 </tr> 121 </table> 122 <p> 123 If the operation is successful, <code>android</code> lists to STDOUT the names of the files 124 and directories it has created. 125 </p> 126 <p> 127 This creates a new test project with the appropriate directories and build files. The directory 128 structure and build file contents are identical to those in a regular Android application 129 project. They are described in detail in the topic 130 <a href="{@docRoot}guide/developing/other-ide.html">Developing In Other IDEs</a>. 131 </p> 132 <p> 133 The operation also creates an <code>AndroidManifest.xml</code> file with instrumentation 134 information. When you run the test, Android uses this information to load the application you 135 are testing and control it with instrumentation. 136 </p> 137 <p> 138 For example, suppose you create the <a 139 href="{@docRoot}resources/tutorials/hello-world.html">Hello, World</a> tutorial application 140 in the directory <code>~/source/HelloAndroid</code>. In the tutorial, this application uses the 141 package name <code>com.example.helloandroid</code> and the activity name 142 <code>HelloAndroid</code>. You can to create the test for this in 143 <code>~/source/HelloAndroidTest</code>. To do so, you enter: 144 </p> 145 <pre> 146 $ cd ~/source 147 $ android create test-project -m ../HelloAndroid -n HelloAndroidTest -p HelloAndroidTest 148 </pre> 149 <p> 150 This creates a directory called <code>~/src/HelloAndroidTest</code>. In the new directory you 151 see the file <code>AndroidManifest.xml</code>. This file contains the following 152 instrumentation-related elements and attributes: 153 </p> 154 <ul> 155 <li> 156 <code><application></code>: to contain the 157 <code><uses-library></code> element. 158 </li> 159 <li> 160 <code><uses-library android:name="android.test.runner"</code>: 161 specifies this testing application uses the <code>android.test.runner</code> library. 162 </li> 163 <li> 164 <code><instrumentation></code>: contains attributes that control Android 165 instrumentation. The attributes are: 166 <ul> 167 <li> 168 <code>android:name="android.test.InstrumentationTestRunner"</code>: 169 {@link android.test.InstrumentationTestRunner} runs test cases. It extends both 170 JUnit test case runner classes and Android instrumentation classes. 171 </li> 172 <li> 173 <code>android:targetPackage="com.example.helloandroid"</code>: specifies 174 that the tests in HelloAndroidTest should be run against the application with the 175 <em>Android</em> package name <code>com.example.helloandroid</code>. This is the 176 package name of the <a 177 href="{@docRoot}resources/tutorials/hello-world.html">Hello, World</a> 178 tutorial application. 179 </li> 180 <li> 181 <code>android:label="Tests for .HelloAndroid"</code>: specifies a 182 user-readable label for the instrumentation class. By default, 183 the <code>android</code> tool gives it the value "Tests for " plus 184 the name of the main Activity of the application under test. 185 </li> 186 </ul> 187 </li> 188 </ul> 189 <h3 id="UpdateTestProject">Updating a test project</h3> 190 <p> 191 You use the <code>android</code> tool when you need to change the path to the 192 project of the application under test. If you are changing an existing test project created in 193 Eclipse with ADT so that you can also build and run it from the command line, you must use the 194 "create" operation. See the section <a href="#CreateTestProject">Creating a test project</a>. 195 </p> 196 <p class="note"> 197 <strong>Note:</strong> If you change the Android package name of the application under test, 198 you must <em>manually</em> change the value of the <code><android:targetPackage></code> 199 attribute within the <code>AndroidManifest.xml</code> file of the test application. 200 Running <code>android update test-project</code> does not do this. 201 </p> 202 <p> 203 To update a test project with the <code>android</code> tool, enter: 204 </p> 205 <pre>android update-test-project -m <main_path> -p <test_path></pre> 206 207 <table> 208 <tr> 209 <th>Flag</th> 210 <th>Value</th> 211 <th>Description</th> 212 </tr> 213 <tr> 214 <td><code>-m, --main</code></td> 215 <td>The path to the project of the application under test, relative to the test project</td> 216 <td> 217 For example, if the application under test is in <code>source/HelloAndroid</code>, and 218 the test project is in <code>source/HelloAndroidTest</code>, then the value for 219 <code>--main</code> is <code>../HelloAndroid</code>. 220 </td> 221 </tr> 222 <tr> 223 <td><code>-p, --path</code></td> 224 <td>The of the test project.</td> 225 <td> 226 For example, if the test project is in <code>source/HelloAndroidTest</code>, then the 227 value for <code>--path</code> is <code>HelloAndroidTest</code>. 228 </td> 229 </tr> 230 </table> 231 <p> 232 If the operation is successful, <code>android</code> lists to STDOUT the names of the files 233 and directories it has created. 234 </p> 235 <h2 id="CreateTestApp">Creating a Test Application</h2> 236 <p> 237 Once you have created a test project, you populate it with a test application. 238 The application does not require an {@link android.app.Activity Activity}, 239 although you can define one if you wish. Although your test application can 240 combine Activities, Android test class extensions, JUnit extensions, or 241 ordinary classes, you should extend one of the Android test classes or JUnit classes, 242 because these provide the best testing features. 243 </p> 244 <p> 245 If you run your tests with {@link android.test.InstrumentationTestRunner} 246 (or a related test runner), then it will run all the methods in each class. You can modify 247 this behavior by using the {@link junit.framework.TestSuite TestSuite} class. 248 </p> 249 250 <p> 251 To create a test application, start with one of Android's test classes in the Java package 252 {@link android.test android.test}. These extend the JUnit 253 {@link junit.framework.TestCase TestCase} class. With a few exceptions, the Android test 254 classes also provide instrumentation for testing. 255 </p> 256 <p> 257 For test classes that extend {@link junit.framework.TestCase TestCase}, you probably want to 258 override the <code>setUp()</code> and <code>tearDown()</code> methods: 259 </p> 260 <ul> 261 <li> 262 <code>setUp()</code>: This method is invoked before any of the test methods in the class. 263 Use it to set up the environment for the test. You can use <code>setUp()</code> 264 to instantiate a new <code>Intent</code> object with the action <code>ACTION_MAIN</code>. 265 You can then use this intent to start the Activity under test. 266 <p class="note"> 267 <strong>Note:</strong> If you override this method, call 268 <code>super.setUp()</code> as the first statement in your code. 269 </p> 270 </li> 271 <li> 272 <code>tearDown()</code>: This method is invoked after all the test methods in the class. Use 273 it to do garbage collection and re-setting before moving on to the next set of tests. 274 <p class="note"><strong>Note:</strong> If you override this method, you must call 275 <code>super.tearDown()</code> as the <em>last</em> statement in your code.</p> 276 </li> 277 </ul> 278 <p> 279 Another useful convention is to add the method <code>testPreConditions()</code> to your test 280 class. Use this method to test that the application under test is initialized correctly. If this 281 test fails, you know that that the initial conditions were in error. When this happens, further 282 test results are suspect, regardless of whether or not the tests succeeded. 283 </p> 284 <p> 285 To learn more about creating test applications, see the topic <a 286 href="{@docRoot}guide/topics/testing/testing_android.html">Testing and Instrumentation</a>, 287 which provides an overview of Android testing. If you prefer to follow a tutorial, 288 try the <a href="{@docRoot}resources/tutorials/testing/activity_test.html">Activity Testing</a> 289 tutorial, which leads you through the creation of tests for an actual Android application. 290 </p> 291 <h2 id="RunTestsCommand">Running Tests</h2> 292 <p> 293 If you are not developing in Eclipse with ADT, you need to run tests from the command line. 294 You can do this either with Ant or with the {@link android.app.ActivityManager ActivityManager} 295 command line interface. 296 </p> 297 <p> 298 You can also run tests from the command line even if you are using Eclipse with ADT to develop 299 them. To do this, you need to create the proper files and directory structure in the test 300 project, using the <code>android</code> tool with the option <code>create test-project</code>. 301 This is described in the section <a 302 href="#CreateTestProjectCommand">Working with Test Projects</a>. 303 </p> 304 <h3 id="RunTestsAnt">Quick build and run with Ant</h3> 305 <p> 306 You can use Ant to run all the tests in your test project, using the target 307 <code>run-tests</code>, which is created automatically when you create a test project with 308 the <code>android</code> tool. 309 </p> 310 <p> 311 This target re-builds your main project and test project if necessary, installs the test 312 application to the current AVD or device, and then runs all the test classes in the test 313 application. The results are directed to <code>STDOUT</code>. 314 </p> 315 <p> 316 You can update an existing test project to use this feature. To do this, use the 317 <code>android</code> tool with the <code>update test-project</code> option. This is described 318 in the section <a href="#UpdateTestProject">Updating a test project</a>. 319 <h3 id="RunTestsDevice">Running tests on a device or emulator</h3> 320 <p> 321 When you run tests from the command line with the ActivityManager (<code>am</code>) 322 command-line tool, you get more options for choosing the tests to run than with any other 323 method. You can select individual test methods, filter tests according to their annotation, or 324 specify testing options. Since the test run is controlled entirely from a command line, you can 325 customize your testing with shell scripts in various ways. 326 </p> 327 <p> 328 You run the <code>am</code> tool on an Android device or emulator using the 329 <a href="{@docRoot}guide/developing/tools/adb.html">Android Debug Bridge</a> 330 (<code>adb</code>) shell. When you do this, you use the ActivityManager 331 <code>instrument</code> option to run your test application using an Android test runner 332 (usually {@link android.test.InstrumentationTestRunner}). You set <code>am</code> 333 options with command-line flags. 334 </p> 335 <p> 336 To run a test with <code>am</code>: 337 </p> 338 <ol> 339 <li> 340 If necessary, re-build your main application and test application. 341 </li> 342 <li> 343 Install your test application and main application Android package files 344 (<code>.apk</code> files) to your current Android device or emulator</li> 345 <li> 346 At the command line, enter: 347 <pre> 348 $ adb shell am instrument -w <test_package_name>/<runner_class> 349 </pre> 350 <p> 351 where <code><test_package_name></code> is the Android package name of your test 352 application, and <code><runner_class></code> is the name of the Android test runner 353 class you are using. The Android package name is the value of the <code>package</code> 354 attribute of the <code>manifest</code> element in the manifest file 355 (<code>AndroidManifest.xml</code>) of your test application. The Android test runner 356 class is usually <code>InstrumentationTestRunner</code>. 357 </p> 358 <p>Your test results appear in <code>STDOUT</code>.</p> 359 </li> 360 </ol> 361 <p> 362 This operation starts an <code>adb</code> shell, then runs <code>am instrument</code> in it 363 with the specified parameters. This particular form of the command will run all of the tests 364 in your test application. You can control this behavior with flags that you pass to 365 <code>am instrument</code>. These flags are described in the next section. 366 </p> 367 <h2 id="AMSyntax">Using the Instrument Command</h2> 368 <p> 369 The general syntax of the <code>am instrument</code> command is: 370 </p> 371 <pre> 372 am instrument [flags] <test_package>/<runner_class> 373 </pre> 374 <p> 375 The main input parameters to <code>am instrument</code> are described in the following table: 376 </p> 377 <table> 378 <tr> 379 <th> 380 Parameter 381 </th> 382 <th> 383 Value 384 </th> 385 <th> 386 Description 387 </th> 388 </tr> 389 <tr> 390 <td> 391 <code><test_package></code> 392 </td> 393 <td> 394 The Android package name of the test application. 395 </td> 396 <td> 397 The value of the <code>package</code> attribute of the <code>manifest</code> 398 element in the test application's manifest file. 399 </td> 400 </tr> 401 <tr> 402 <td> 403 <code><runner_class></code> 404 </td> 405 <td> 406 The class name of the instrumented test runner you are using. 407 </td> 408 <td> 409 This is usually {@link android.test.InstrumentationTestRunner}. 410 </td> 411 </tr> 412 </table> 413 <p> 414 The flags for <code>am instrument</code> are described in the following table: 415 </p> 416 <table> 417 <tr> 418 <th> 419 Flag 420 </th> 421 <th> 422 Value 423 </th> 424 <th> 425 Description 426 </th> 427 </tr> 428 <tr> 429 <td> 430 <code>-w</code> 431 </td> 432 <td> 433 (none) 434 </td> 435 <td> 436 Forces <code>am instrument</code> to wait until the instrumentation terminates 437 before terminating itself. The net effect is to keep the shell open until the tests 438 have finished. This flag is not required, but if you do not use it, you will not 439 see the results of your tests. 440 </td> 441 </tr> 442 <tr> 443 <td> 444 <code>-r</code> 445 </td> 446 <td> 447 (none) 448 </td> 449 <td> 450 Outputs results in raw format. Use this flag when you want to collect 451 performance measurements, so that they are not formatted as test results. This flag is 452 designed for use with the flag <code>-e perf true</code> (documented in the section 453 <a href="#AMOptionsSyntax">Instrument options</a>). 454 </td> 455 </tr> 456 <tr> 457 <td> 458 <code>-e</code> 459 </td> 460 <td> 461 <test_options> 462 </td> 463 <td> 464 Provides testing options , in the form of key-value pairs. The 465 <code>am instrument</code> tool passes these to the specified instrumentation class 466 via its <code>onCreate()</code> method. You can specify multiple occurrences of 467 <code>-e <test_options</code>. The keys and values are described in the next table. 468 <p> 469 The only instrumentation class that understands these key-value pairs is 470 <code>InstrumentationTestRunner</code> (or a subclass). Using them with 471 any other class has no effect. 472 </p> 473 </td> 474 </tr> 475 </table> 476 477 <h3 id="AMOptionsSyntax">Instrument options</h3> 478 <p> 479 The <code>am instrument</code> tool passes testing options to 480 <code>InstrumentationTestRunner</code> or a subclass in the form of key-value pairs, 481 using the <code>-e</code> flag, with this syntax: 482 </p> 483 <pre> 484 -e <key> <value> 485 </pre> 486 <p> 487 Where applicable, a <key> may have multiple values separated by a comma (,). 488 For example, this invocation of <code>InstrumentationTestRunner</code> provides multiple 489 values for the <code>package</code> key: 490 <pre> 491 $ adb shell am instrument -w -e package com.android.test.package1,com.android.test.package2 com.android.test/android.test.InstrumentationTestRunner 492 </pre> 493 <p> 494 The following table describes the key-value pairs and their result. Please review the 495 <strong>Usage Notes</strong> following the table. 496 </p> 497 <table> 498 <tr> 499 <th>Key</th> 500 <th>Value</th> 501 <th>Description</th> 502 </tr> 503 <tr> 504 <td> 505 <code>package</code> 506 </td> 507 <td> 508 <Java_package_name> 509 </td> 510 <td> 511 The fully-qualified <em>Java</em> package name for one of the packages in the test 512 application. Any test case class that uses this package name is executed. Notice that this 513 is not an <em>Android</em> package name; a test application has a single Android package 514 name but may have several Java packages within it. 515 </td> 516 </tr> 517 <tr> 518 <td rowspan="2"><code>class</code></td> 519 <td><class_name></td> 520 <td> 521 The fully-qualified Java class name for one of the test case classes. Only this test case 522 class is executed. 523 </td> 524 </tr> 525 <tr> 526 <td><class_name><strong>#</strong>method name</td> 527 <td> 528 A fully-qualified test case class name, and one of its methods. Only this method is 529 executed. Note the hash mark (#) between the class name and the method name. 530 </td> 531 </tr> 532 <tr> 533 <td><code>func</code></td> 534 <td><code>true</code></td> 535 <td> 536 Runs all test classes that extend {@link android.test.InstrumentationTestCase}. 537 </td> 538 </tr> 539 <tr> 540 <td><code>unit</code></td> 541 <td><code>true</code></td> 542 <td> 543 Runs all test classes that do <em>not</em> extend either 544 {@link android.test.InstrumentationTestCase} or {@link android.test.PerformanceTestCase}. 545 </td> 546 </tr> 547 <tr> 548 <td><code>size</code></td> 549 <td>[<code>small</code> | <code>medium</code> | <code>large</code>] 550 </td> 551 <td> 552 Runs a test method annotated by size. The annotations are <code>@SmallTest</code>, 553 <code>@MediumTest</code>, and <code>@LargeTest</code>. 554 </td> 555 </tr> 556 <tr> 557 <td><code>perf</code></td> 558 <td><code>true</code></td> 559 <td> 560 Runs all test classes that implement {@link android.test.PerformanceTestCase}. 561 When you use this option, also specify the <code>-r</code> flag for 562 <code>am instrument</code>, so that the output is kept in raw format and not 563 re-formatted as test results. 564 </td> 565 </tr> 566 <tr> 567 <td><code>debug</code></td> 568 <td><code>true</code></td> 569 <td> 570 Runs tests in debug mode. 571 </td> 572 </tr> 573 <tr> 574 <td><code>log</code></td> 575 <td><code>true</code></td> 576 <td> 577 Loads and logs all specified tests, but does not run them. The test 578 information appears in <code>STDOUT</code>. Use this to verify combinations of other filters 579 and test specifications. 580 </td> 581 </tr> 582 <tr> 583 <td><code>emma</code></td> 584 <td><code>true</code></td> 585 <td> 586 Runs an EMMA code coverage analysis and writes the output to <code>/data//coverage.ec</code> 587 on the device. To override the file location, use the <code>coverageFile</code> key that 588 is described in the following entry. 589 <p class="note"> 590 <strong>Note:</strong> This option requires an EMMA-instrumented build of the test 591 application, which you can generate with the <code>coverage</code> target. 592 </p> 593 </td> 594 </tr> 595 <tr> 596 <td><code>coverageFile</code></td> 597 <td><code><filename></code></td> 598 <td> 599 Overrides the default location of the EMMA coverage file on the device. Specify this 600 value as a path and filename in UNIX format. The default filename is described in the 601 entry for the <code>emma</code> key. 602 </td> 603 </tr> 604 </table> 605 <strong><code>-e</code> Flag Usage Notes</strong> 606 <ul> 607 <li> 608 <code>am instrument</code> invokes 609 {@link android.test.InstrumentationTestRunner#onCreate(Bundle)} 610 with a {@link android.os.Bundle} containing the key-value pairs. 611 </li> 612 <li> 613 The <code>package</code> key takes precedence over the <code>class</code> key. If you 614 specifiy a package, and then separately specify a class within that package, Android 615 will run all the tests in the package and ignore the <code>class</code> key. 616 </li> 617 <li> 618 The <code>func</code> key and <code>unit</code> key are mutually exclusive. 619 </li> 620 </ul> 621 <h3 id="RunTestExamples">Instrument examples</h3> 622 <p> 623 Here are some examples of using <code>am instrument</code> to run tests. They are based on 624 the following structure:</p> 625 <ul> 626 <li> 627 The test application has the Android package name <code>com.android.demo.app.tests</code> 628 </li> 629 <li> 630 There are three test classes: 631 <ul> 632 <li> 633 <code>UnitTests</code>, which contains the methods 634 <code>testPermissions</code> and <code>testSaveState</code>. 635 </li> 636 <li> 637 <code>FunctionTests</code>, which contains the methods 638 <code>testCamera</code>, <code>testXVGA</code>, and <code>testHardKeyboard</code>. 639 </li> 640 <li> 641 <code>IntegrationTests</code>, 642 which contains the method <code>testActivityProvider</code>. 643 </li> 644 </ul> 645 </li> 646 <li> 647 The test runner is {@link android.test.InstrumentationTestRunner}. 648 </li> 649 </ul> 650 <h4>Running the Entire Test Application</h4> 651 <p> 652 To run all of the test classes in the test application, enter: 653 </p> 654 <pre> 655 $ adb shell am instrument -w com.android.demo.app.tests/android.test.InstrumentationTestRunner 656 </pre> 657 <h4>Running All Tests in a Test Case Class</h4> 658 <p> 659 To run all of the tests in the class <code>UnitTests</code>, enter: 660 </p> 661 <pre> 662 $ adb shell am instrument -w \ 663 -e class com.android.demo.app.tests.UnitTests \ 664 com.android.demo.app.tests/android.test.InstrumentationTestRunner 665 </pre> 666 <p> 667 <code>am instrument</code> gets the value of the <code>-e</code> flag, detects the 668 <code>class</code> keyword, and runs all the methods in the <code>UnitTests</code> class. 669 </p> 670 <h4>Selecting a Subset of Tests</h4> 671 <p> 672 To run all of the tests in <code>UnitTests</code>, and the <code>testCamera</code> method in 673 <code>FunctionTests</code>, enter: 674 </p> 675 <pre> 676 $ adb shell am instrument -w \ 677 -e class com.android.demo.app.tests.UnitTests,com.android.demo.app.tests.FunctionTests#testCamera \ 678 com.android.demo.app.tests/android.test.InstrumentationTestRunner 679 </pre> 680 <p> 681 You can find more examples of the command in the documentation for 682 {@link android.test.InstrumentationTestRunner}. 683 </p> 684
