docs: Refactor testing docs to remove/update obsolete guidance:
* Added new 'Getting Started with Testing' training to contain common
information on how to configure and run tests with Android Studio.
* Removed the obsolete 'Testing Your Activity' training.
* Deleted obsolete testing content under 'Tools > Workflow'.
* Moved accessibility testing checklist to 'Implementing accessibility'
training section.
* Moved content provider and service testing topics into a new
'Testing App Integrations' training.
* Updated the service testing training to reflect our recommended
approach of using ServiceTestRule, instead of ServiceTestCase.
* Renamed 'Testing from Other IDEs' topic to
'Testing from the Command Line' and moved it under 'Testing Tools'.
* Revised 'Testing Fundamentals' topic and moved it under 'Testing Tools'.
* Updated the landing page fo 'Best Practises for Testing' to provide a
central location for testing-related resources.
bug: 20722624
Change-Id: Ic1cbc79b48916dcae1c09bf5114ba8aef13d6f27
diff --git a/docs/html/training/testing/index.jd b/docs/html/training/testing/index.jd
new file mode 100644
index 0000000..d6405c8
--- /dev/null
+++ b/docs/html/training/testing/index.jd
@@ -0,0 +1,72 @@
+page.title=Best Practices for Testing
+page.article=true
+page.image=images/testing/hwtest_junit_success.png
+
+meta.tags="testing"
+page.tags="testing"
+
+page.metaDescription=Starting point for testing Android apps, with guidelines, information, and examples.
+
+@jd:body
+
+<img src="/images/testing/testing-icon.png"
+style="float:right; margin:0 0 20px 30px" width="245" height="229" />
+
+<p>
+ Testing your app is an integral part of the app development process. Testing allows you to verify
+ the correctness, functional behavior, and usability of your app before it is released publicly.
+</p>
+<br>
+<br>
+
+<h2 id="start">Get Started</h2>
+
+<p>
+ Learn the basics of testing your app, with information about building and running your tests with
+ Android Studio:
+</p>
+
+<div class="resource-widget resource-flow-layout col-12"
+ data-query="collection:training/testing/overview"
+ data-cardSizes="6x3"
+ data-maxresults="3">
+</div>
+
+
+<h2 id="tools">Testing Tools and APIs</h2>
+
+<p>
+ Learn about the tools provided by the Android platform that help you test every aspect of your app
+ at every level:
+</p>
+
+<div class="resource-widget resource-flow-layout landing col-12"
+ data-query="collection:training/testing/tools"
+ data-cardSizes="15x3, 9x2, 9x2, 9x2, 9x2"
+ data-maxResults="5">
+</div>
+
+
+<h2 id="techniques">App Testing Techniques</h2>
+
+<p>
+ Learn techniques for testing your apps:
+</p>
+
+<div class="resource-widget resource-flow-layout landing col-12"
+ data-query="collection:training/testing/techniques"
+ data-cardSizes="6x3
+ data-maxResults="3">
+</div>
+
+<h2 id="resources">Other Resources</h2>
+
+<p>
+ More resources for app testing:
+</p>
+
+<div class="resource-widget resource-flow-layout landing col-12"
+ data-query="collection:training/testing/resources"
+ data-cardSizes="9x3"
+ data-maxResults="6">
+</div>
\ No newline at end of file
diff --git a/docs/html/training/testing/integration-testing/content-provider-testing.jd b/docs/html/training/testing/integration-testing/content-provider-testing.jd
new file mode 100644
index 0000000..75869d9
--- /dev/null
+++ b/docs/html/training/testing/integration-testing/content-provider-testing.jd
@@ -0,0 +1,174 @@
+page.title=Testing Your Content Provider
+page.tags=testing, content provider
+trainingnavtop=true
+
+@jd:body
+
+<!-- This is the training bar -->
+<div id="tb-wrapper">
+<div id="tb">
+ <h2>Dependencies and Prerequisites</h2>
+
+ <ul>
+ <li>Android 2.2 (API level 8) or higher</li>
+ <li><a href="{@docRoot}tools/testing-support-library/index.html">
+ Android Testing Support Library</a></li>
+ <li><a href="{@docRoot}tools/studio/index.html">Android Studio 1.4.1 or higher</a>.</li>
+ </ul>
+
+ <h2>This lesson teaches you to</h2>
+
+ <ol>
+ <li><a href="#build">Create Integration Tests for Content Providers</a></li>
+ <li><a href="#WhatToTest">What to Test</a></li>
+ </ol>
+
+ <h2>You should also read</h2>
+ <ul>
+ <li><a href="{@docRoot}guide/topics/providers/content-providers.html">Content Providers</a>
+ </li>
+ </ul>
+</div>
+</div>
+
+<p>
+ If you are implementing a <a href="{@docRoot}guide/topics/providers/content-providers.html">
+ content provider</a> to store and retrieve data or to make data
+ accessible to other apps, you should test your provider to ensure that it doesn't behave in an
+ unexpected way. This lesson describes how to test public content providers, and is also
+ applicable to providers that you keep private to your own app.
+</p>
+<h2 id="build">Create Integration Tests for Content Providers</h2>
+<p>
+In Android, apps view content providers 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.
+For this reason, 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.
+</p>
+<p>
+Content providers let you access actual user data, so it's important to ensure
+that you test the content provider in an isolated testing environment. This approach allows you to
+only run against data dependencies set explicitly in the test case. It also means that your tests
+do not modify actual user data. For example, you should avoid writing a test that fails because
+there was data left over from a previous test. Similarly, your test should avoid adding or deleting
+actual contact information in a provider.
+</p>
+
+<p>
+To test your content provider in isolation, use the {@link android.test.ProviderTestCase2} class.
+This class allows you to use Android mock object classes such as {@link android.test.IsolatedContext}
+and {@link android.test.mock.MockContentResolver} to access file and database information without
+affecting the actual user data.
+</p>
+
+<p>Your integration test should be written as a JUnit 4 test class. To learn more about creating
+JUnit 4 test classes and using JUnit 4 assertions, see
+<a href="{@docRoot}training/testing/unit-testing/local-unit-tests.html#build">
+Create a Local Unit Test Class</a>.</p>
+
+<p>To create an integration test for your content provider, you must perform these steps:</p>
+<ul>
+ <li>Create your test class as a subclass of {@link android.test.ProviderTestCase2}.</li>
+ <li>Add the
+{@code @RunWith(AndroidJUnit4.class)} annotation at the beginning of your test class
+definition.</li>
+ <li>Specify the
+<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+{@code AndroidJUnitRunner}</a> class that the
+<a href="{@docRoot}tools/testing-support-library/index.html">Android Testing Support Library</a>
+provides as your default test runner. This step is described in more detail in
+<a href="{@docRoot}training/testing/start/index.html#run-instrumented-tests">
+Getting Started with Testing</a>.</li>
+ <li>Set the {@link android.content.Context} object from the
+<a href="{@docRoot}reference/android/support/test/InstrumentationRegistry.html">
+{@code InstrumentationRegistry}</a> class. See the snippet below for an example.
+ <pre>
+@Override
+protected void setUp() throws Exception {
+ setContext(InstrumentationRegistry.getTargetContext());
+ super.setUp();
+}</pre>
+ </li>
+</ul>
+
+<h3 id="ProviderTestCase2">How ProviderTestCase2 works</h3>
+<p>
+ 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.
+</p>
+<p>
+ 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.
+</p>
+<p>
+ The constructor then creates a {@link android.test.mock.MockContentResolver} to use as the
+ resolver for the test.
+</p>
+<p>
+ 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.
+</p>
+
+<p>
+You run integration tests for content providers the same way as instrumented unit tests. To run the
+integration test for your content provider, follow the steps described in <a
+href="{@docRoot}training/testing/unit-testing/instrumented-unit-tests.html#run">
+Run Instrumented Unit Tests</a>.
+</p>
+
+<h2 id="WhatToTest">What to Test</h2>
+<p>
+Here are some specific guidelines for testing content providers.
+</p>
+<ul>
+ <li>
+ Test with resolver methods: Even though you can instantiate a provider object in
+ {@link android.test.ProviderTestCase2}, you should always test with a resolver object
+ using the appropriate URI. Doing so ensures that you are testing the provider by performing
+ the same interaction that a regular application would use.
+ </li>
+ <li>
+ Test a public provider as a contract: If you intend your provider to be public and
+ available to other applications, you should test it as a contract. Some examples of how to
+ do so are as follows:
+ <ul>
+ <li>
+ Test with constants that your provider publicly exposes. For
+ example, look for constants that refer to column names in one of the provider's
+ data tables. These should always be constants publicly defined by the provider.
+ </li>
+ <li>
+ Test all the URIs that your provider offers. Your provider may offer several URIs,
+ each one referring to a different aspect of the data.
+ </li>
+ <li>
+ Test invalid URIs: Your unit tests should deliberately call the provider with an
+ invalid URI, and look for errors. A good provider design is to throw an
+ {@code IllegalArgumentException} for invalid URIs.
+
+ </li>
+ </ul>
+ </li>
+ <li>
+ Test the standard provider interactions: Most providers offer six access methods:
+ {@code query()}, {@code insert()}, {@code delete()}, {@code update()},
+ {@code getType()}, and {@code onCreate()}. Your tests should verify that all
+ of these methods work. These methods are described in more detail in the topic
+ <a href="{@docRoot}guide/topics/providers/content-providers.html">Content Providers</a>.
+ </li>
+ <li>
+ Test business logic: If the content provider implements business logic, you should test it.
+ Business logic includes handling of invalid values, financial or arithmetic calculations,
+ elimination or combining of duplicates.
+ </li>
+</ul>
\ No newline at end of file
diff --git a/docs/html/training/testing/integration-testing/index.jd b/docs/html/training/testing/integration-testing/index.jd
new file mode 100644
index 0000000..d7ce899
--- /dev/null
+++ b/docs/html/training/testing/integration-testing/index.jd
@@ -0,0 +1,55 @@
+page.title=Testing App Component Integrations
+page.tags=testing,integration
+
+trainingnavtop=true
+startpage=true
+
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+ <h2>
+ You should also read
+ </h2>
+ <ul>
+ <li>
+ <a href="{@docRoot}tools/testing-support-library/index.html">Testing Support Library</a>
+ </li>
+ </ul>
+</div>
+</div>
+
+<p>
+If your app uses components that users do not directly interact with, such as
+a <a href="{@docRoot}guide/components/services.html">Service</a> or
+<a href="{@docRoot}guide/topics/providers/content-providers.html">Content Provider</a>, you
+should validate that these components behave in a correct way with your app.</p>
+<p>When developing such components, you should get into the habit of writing
+<em>integration tests</em> in order to validate the component's behavior when your app runs on a
+device or an emulator.</p>
+
+<p class="note"><strong>Note:</strong> Android does not provide a separate test case class for
+{@link android.content.BroadcastReceiver}. To verify that a
+{@link android.content.BroadcastReceiver} responds correctly, you can test the component that sends
+it an {@link android.content.Intent} object. Alternatively, you can create an instance of your
+{@link android.content.BroadcastReceiver} by calling
+<a href="{@docRoot}reference/android/support/test/InstrumentationRegistry.html#getContext()">
+{@code InstrumentationRegistry.getTargetContext()}</a>, then call the
+{@link android.content.BroadcastReceiver} method that you want to test (usually, this is
+the
+{@link android.content.BroadcastReceiver#onReceive(android.content.Context, android.content.Intent)
+onReceive()} method).</p>
+
+<p>This class teaches you to build automated integration tests using the testing APIs and tools
+that the Android platform provides.</p>
+<h2>Lessons</h2>
+<dl>
+ <dt><strong><a href="service-testing.html">
+Testing Your Service</a></strong></dt>
+ <dd>Learn how to build integration tests to verify that a service works correctly with your
+ app.</dd>
+ <dt><strong><a href="content-provider-testing.html">
+Testing Your Content Provider</a></strong></dt>
+ <dd>Learn how to build integration tests to verify that a content provider works correctly with
+ your app.</dd>
+</dl>
\ No newline at end of file
diff --git a/docs/html/training/testing/integration-testing/service-testing.jd b/docs/html/training/testing/integration-testing/service-testing.jd
new file mode 100644
index 0000000..7b420ac
--- /dev/null
+++ b/docs/html/training/testing/integration-testing/service-testing.jd
@@ -0,0 +1,140 @@
+page.title=Testing Your Service
+page.tags=testing, service
+trainingnavtop=true
+
+@jd:body
+
+<!-- This is the training bar -->
+<div id="tb-wrapper">
+<div id="tb">
+ <h2>Dependencies and Prerequisites</h2>
+
+ <ul>
+ <li>Android 2.2 (API level 8) or higher</li>
+ <li><a href="{@docRoot}tools/testing-support-library/index.html">
+ Android Testing Support Library</a></li>
+ <li><a href="{@docRoot}tools/studio/index.html">Android Studio 1.4.1 or higher</a>.</li>
+ </ul>
+
+ <h2>This lesson teaches you to</h2>
+
+ <ol>
+ <li><a href="#setup">Set Up Your Testing Environment</a></li>
+ <li><a href="#build">Create an Integrated Test for Services</a></li>
+ <li><a href="#run">Run Integration Tests for Services</a></li>
+ </ol>
+
+ <h2>You should also read</h2>
+ <ul>
+ <li><a href="{@docRoot}guide/components/services.html">Services</a></li>
+ </ul>
+
+ <h2>Try it out</h2>
+
+ <ul>
+ <li>
+<a href="https://github.com/googlesamples/android-testing/tree/master/integration/ServiceTestRuleSample"
+class="external-link">Service Test Code Samples</a></li>
+ </ul>
+</div>
+</div>
+
+<p>
+If you are implementing a local {@link android.app.Service} as a component of
+your app, you should test the {@link android.app.Service} to ensure that it doesn't behave in an
+unexpected way. You can create
+<a href="{@docRoot}training/testing/unit-testing/instrumented-unit-tests.html">
+instrumented unit tests</a> to verify that the behavior in the {@link android.app.Service}
+is correct; for example, the service stores and returns valid data values and performs
+data operations correctly.
+</p>
+
+<p>
+The <a href="{@docRoot}tools/testing-support-library/index.html">Android Testing Support Library</a>
+provides an API for testing your {@link android.app.Service} objects in isolation.
+The
+<a href="{@docRoot}reference/android/support/test/rule/ServiceTestRule.html">ServiceTestRule</a>
+class is a JUnit 4 rule that starts your service before your unit test methods
+run, and shuts down the service after tests complete. By using this test rule, you ensure that the
+connection to the service is always established before your test method runs. To
+learn more about JUnit 4 rules, see the <a href="https://github.com/junit-team/junit/wiki/Rules"
+class="external-link">JUnit documentation</a>.
+</p>
+
+<p style="note">
+<strong>Note</strong>: The
+<a href="{@docRoot}reference/android/support/test/rule/ServiceTestRule.html">ServiceTestRule</a>
+class does not support testing of {@link android.app.IntentService} objects.
+If you need to test a {@link android.app.IntentService} object, you should encapsulate the logic
+in a separate class and create a corresponding unit test instead.
+</p>
+
+<h2 id="setup">Set Up Your Testing Environment</h2>
+<p>Before building your integration test for the service, make sure to configure your project for
+ instrumented tests, as described in
+<a href="{@docRoot}training/testing/start/index.html#config-instrumented-tests">
+Getting Started with Testing</a>.</p>
+
+<h2 id="build">Create an Integration Test for Services</h2>
+<p>Your integration test should be written as a JUnit 4 test class. To learn more about creating
+JUnit 4 test classes and using JUnit 4 assertion methods, see
+<a href="{@docRoot}training/testing/unit-testing/instrumented-unit-tests.html#build">
+Create an Instrumented Unit Test Class</a>.</p>
+
+<p>To create an integration test for your service, add the {@code @RunWith(AndroidJUnit4.class)}
+annotation at the beginning of your test class definition. You also need to specify the
+<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+{@code AndroidJUnitRunner}</a> class that the Android Testing Support Library provides as your
+default test runner. This step is described in more detail in
+<a href="{@docRoot}training/testing/unit-testing/instrumented-unit-tests.html#run">
+Run Instrumented Unit Tests</a>.</p>
+
+<p>Next, create a
+<a href="{@docRoot}reference/android/support/test/rule/ServiceTestRule.html">ServiceTestRule</a>
+instance in your test by using the {@code @Rule} annotation.</p>
+
+<pre>
+@Rule
+public final ServiceTestRule mServiceRule = new ServiceTestRule();
+</pre>
+
+<p>The following example shows how you might implement an integration test for a service.
+The test method {@code testWithBoundService} verifies that the app binds successfully to a
+local service and that the service interface behaves correctly.</p>
+
+<pre>
+@Test
+public void testWithBoundService() throws TimeoutException {
+ // Create the service Intent.
+ Intent serviceIntent =
+ new Intent(InstrumentationRegistry.getTargetContext(),
+ LocalService.class);
+
+ // Data can be passed to the service via the Intent.
+ serviceIntent.putExtra(LocalService.SEED_KEY, 42L);
+
+ // Bind the service and grab a reference to the binder.
+ IBinder binder = mServiceRule.bindService(serviceIntent);
+
+ // Get the reference to the service, or you can call
+ // public methods on the binder directly.
+ LocalService service =
+ ((LocalService.LocalBinder) binder).getService();
+
+ // Verify that the service is working correctly.
+ assertThat(service.getRandomInt(), is(any(Integer.class)));
+}
+</pre>
+
+<h2 id="run">Run Integration Tests for Services</h2>
+<p>
+You can run integration tests from <a href="{@docRoot}sdk/index.html">Android Studio</a> or
+from the command-line. Make sure to specify
+<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+ {@code AndroidJUnitRunner}</a> as the default instrumentation runner in your project.
+</p>
+<p>
+To run the integration test for your service, follow the steps for running instrumented tests
+described in <a href="{@docRoot}training/testing/start/index.html#run-instrumented-tests">
+Getting Started with Testing</a>.
+</p>
diff --git a/docs/html/training/testing/performance.jd b/docs/html/training/testing/performance.jd
index 2b968b3..8592c0f 100644
--- a/docs/html/training/testing/performance.jd
+++ b/docs/html/training/testing/performance.jd
@@ -28,6 +28,7 @@
</ul>
</li>
</ol>
+
</div>
</div>
diff --git a/docs/html/training/testing/start/index.jd b/docs/html/training/testing/start/index.jd
new file mode 100644
index 0000000..a4b4aea
--- /dev/null
+++ b/docs/html/training/testing/start/index.jd
@@ -0,0 +1,252 @@
+page.title=Getting Started with Testing
+page.tags="testing"
+page.article=true
+page.image=images/tools/studio-main-screen.png
+
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+
+<!-- Required platform, tools, add-ons, devices, knowledge, etc. -->
+<h2>Dependencies and prerequisites</h2>
+<ul>
+ <li><a href="{@docRoot}tools/studio/index.html">Android Studio (latest version)</a>.</li>
+</ul>
+
+<h2>This lesson teaches you to</h2>
+<ol>
+<li><a href="#setup">Set Up Your Testing Environment</a></li>
+<li><a href="#build">Build and Run Your Tests</a></li>
+</ol>
+
+<h2>You Should Also Read</h2>
+<ul>
+<li><a href="{@docRoot}tools/testing/testing_android.html">Testing Concepts</a></li>
+<li><a href="https://github.com/googlesamples/android-testing"
+ class="external-link">Android Testing Samples</a></li>
+<li><a href="{@docRoot}about/dashboards/index.html">Android Dashboards</a></li>
+</ul>
+
+</div>
+</div>
+
+<p>You should be writing and running tests as part of your Android app development cycle.
+Well-written tests can help you catch bugs early in development and give you confidence in your
+code.</p>
+
+<p>To verify specific behavior in your app, and to check for consistency across different Android
+devices, you can write a <a href="//en.wikipedia.org/wiki/Test_case"
+class="external-link">test case</a>. This lesson teaches you how to build a test case using the
+JUnit 4 framework and the testing APIs and tools provided by Google, and how to run your
+tests.</p>
+
+<h2 id="setup">Set Up Your Testing Environment</h2>
+
+<p>Before you start writing and running your tests, you must set up your test
+development environment. Android Studio provides an integrated development environment for you to
+create, build, and run Android app test cases from a graphical user interface (GUI).</p>
+
+<p>You must first download the prerequisite Android development tools before proceeding:
+<ul>
+<li><a href="{@docRoot}sdk/index.html">Android Studio</a> (latest version).</li>
+<li>The latest Android Support Repository using the
+ <a href="{@docRoot}tools/help/sdk-manager.html">SDK Manager</a>. </li>
+</ul>
+
+<p>Based on the type of test you want to create, configure the test code source location and the
+ project dependencies in Android Studio as described in the following sections.</p>
+
+<h3 id="config-local-tests">Configure Your Project for Local Unit Tests</h3>
+<p><em>Local unit tests</em> are tests that run on your local machine, without needing access to the
+Android framework or an Android device. To learn how to develop local units tests, see
+<a href="{@docRoot}training/testing/unit-testing/local-unit-tests.html">
+Building Local Unit Tests</a>.</p>
+<p>In your Android Studio project, you must store the source files for local unit tests under a
+specific source directory ({@code src/test/java}). This feature improves your project organization
+by letting you group your unit tests together into a single source set.</p>
+<p>As with production code, you can create local unit tests for a
+<a href="http://developer.android.com/tools/building/configuring-gradle.html#workBuildVariants"
+class="external-link">specific flavor or build type</a>. Keep your unit tests in a test
+source tree location that corresponds to your production source tree, such as:</p>
+
+<table>
+<tr>
+<th>Path to Production Class</th>
+<th>Path to Local Unit Test Class</th>
+</tr>
+<tr>
+<td>{@code src/main/java/Foo.java}</td>
+<td>{@code src/test/java/FooTest.java}</td>
+</tr>
+<tr>
+<td>{@code src/debug/java/Foo.java}</td>
+<td>{@code src/testDebug/java/FooTest.java}</td>
+</tr>
+<tr>
+<td>{@code src/myFlavor/java/Foo.java}</td>
+<td>{@code src/testMyFlavor/java/FooTest.java}</td>
+</tr>
+</table>
+
+<p>You'll need to configure the testing dependencies for your project to use the
+ standard APIs provided by the JUnit 4 framework. To simplify your local unit test development,
+ we recommend that you include the <a href="https://github.com/mockito/mockito"
+ class="external-link">Mockito</a> library if your test needs to interact with Android
+ dependencies. To learn more about using mock objects in your local unit tests, see
+<a href="{@docRoot}training/testing/unit-testing/local-unit-tests.html#mocking-dependencies">
+ Mocking Android dependencies</a>.</p>
+<p>In the {@code build.gradle} file of your Android app module, specify your dependencies like
+this:</p>
+
+<pre>
+dependencies {
+ // Required -- JUnit 4 framework
+ testCompile 'junit:junit:4.12'
+ // Optional -- Mockito framework
+ testCompile 'org.mockito:mockito-core:1.10.19'
+}
+</pre>
+
+<h3 id="config-instrumented-tests">Configure Your Project for Instrumented Tests</h3>
+<p><em>Instrumented tests</em> are tests that run on an Android device or emulator. These tests
+have access to {@link android.app.Instrumentation} information, such as the
+{@link android.content.Context} for the app under test. Instrumented tests can be used for unit,
+user interface (UI), or app component integration testing. To learn how to develop instrumented
+tests for your specific needs, see these additional topics:
+<ul>
+<li><a href="{@docRoot}training/testing/unit-testing/instrumented-unit-tests.html">
+ Building Instrumented Unit Tests</a> - Build more complex unit tests that have Android
+ dependencies which cannot be easily filled by using mock objects.</li>
+<li><a href="{@docRoot}training/testing/ui-testing/index.html">
+ Automating User Interface Tests</a> - Create tests to verify that the user interface behaves
+ correctly for user interactions within a single app or for interactions across multiple apps.</li>
+<li><a href="{@docRoot}training/testing/integration-testing/index.html">
+ Testing App Component Integrations</a> - Verify the behavior of components that users do not
+directly interact with, such as a <a href="{@docRoot}guide/components/services.html">Service</a> or
+a <a href="guide/topics/providers/content-providers.html">Content Provider</a>.</li>
+</ul>
+</p>
+<p>
+In your Android Studio project, you must place the source code for your instrumentated tests under
+a specific directory (<code>src/androidTest/java</code>).
+</p>
+<p>
+Download the Android Testing Support Library, which provides APIs that allow you to quickly build and
+run instrumented test code for your apps. The Testing Support Library includes a JUnit 4 test runner
+(<a href="{@docRoot}tools/testing-support-library/index.html#AndroidJUnitRunner">AndroidJUnitRunner
+</a>) and APIs for functional UI tests
+(<a href="{@docRoot}tools/testing-support-library/index.html#Espresso">Espresso</a> and
+<a href="{@docRoot}tools/testing-support-library/index.html#UIAutomator">UI Automator</a>). To
+learn how to install the library, see
+<a href="{@docRoot}tools/testing-support-library/index.html#setup">Testing Support Library Setup</a>.
+</p>
+<p>You'll need to configure the Android testing dependencies for your project to use the test runner
+and the rules APIs provided by the Testing Support Library. To simplify your test development,
+we also recommend that you include the <a href="https://github.com/hamcrest"
+class="external-link">Hamcrest</a> library, which lets you create more flexible assertions using the
+Hamcrest matcher APIs.</p>
+<p>In the {@code build.gradle} file of your Android app module, specify your dependencies like
+this:</p>
+<pre>
+dependencies {
+ androidTestCompile 'com.android.support:support-annotations:23.0.1'
+ androidTestCompile 'com.android.support.test:runner:0.4.1'
+ androidTestCompile 'com.android.support.test:rules:0.4.1'
+ // Optional -- Hamcrest library
+ androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
+ // Optional -- UI testing with Espresso
+ androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1'
+ // Optional -- UI testing with UI Automator
+ androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.1'
+}
+</pre>
+
+<h2 id="build">Build and Run Your Tests</h2>
+
+<p>You can run build and run your tests in a similar way to how you run your Android apps --
+ graphically in Android Studio or from the command-line using the
+<a href="{@docRoot}tools/building/plugin-for-gradle.html">
+Android Plugin for Gradle</a>.</p>
+
+<h3 id="run-local-tests">Run Local Unit Tests</h3>
+<p>
+The Android Plugin for Gradle compiles the local unit test code located in the default directory
+({@code src/test/java}), builds a test app, and executes it locally
+using the default test runner class.
+</p>
+<p>
+To run local unit tests in your Gradle project from Android Studio:
+</p>
+<ol>
+<li>In the <strong>Project</strong> window, right click on the project and synchronize your project.
+</li>
+<li>Open the <strong>Build Variants</strong> window by clicking the left-hand tab, then change the
+test artifact to <em>Unit Tests</em>.
+</li>
+<li>In the <strong>Project</strong> window, drill down to your unit test class or method,
+then right-click and run it. To run all tests in the unit test directory, select the directory then
+right-click and press <strong>Run tests</strong>.
+</li>
+</ol>
+
+<p>Android Studio displays the results of the unit test execution in the <strong>Run</strong>
+window.</p>
+
+<p>To run local unit tests in your Gradle project from the command-line, call the {@code test} task
+command.</p>
+
+<pre>
+./gradlew test
+</pre>
+
+<p>If there are failing tests, the command will display links to HTML reports (one per build
+variant). You can find the generated HTML test result reports in the
+{@code <path_to_your_project>/app/build/reports/tests/} directory, and the corresponding XML
+files in the {@code <path_to_your_project>/app/build/test-results/} directory.</p>
+
+<h3 id="run-instrumented-tests">Run Instrumented Tests</h3>
+<p>
+The Android Plugin for Gradle compiles the instrumented test code located in the default directory
+({@code src/androidTest/java}), builds a test APK and production APK, installs both APKs on the
+connected device or emulator, and executes the tests.</p>
+
+<p>Make sure to specify
+<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+{@code AndroidJUnitRunner}</a> as the default test instrumentation runner in your project. To do
+this, add the following setting in your {@code build.gradle} file:</p>
+
+<pre>
+android {
+ defaultConfig {
+ testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
+ }
+}
+</pre>
+
+<p>To run your instrumented tests in Android Studio:</p>
+<ol>
+<li>Open the <strong>Build Variants</strong> window by clicking the left-hand tab, then set the
+test artifact to <em>Android Instrumentation Tests</em>.
+</li>
+<li>In the <strong>Project</strong> window, drill down to your instrumented test class or method,
+ then right-click and run it using the Android Test configuration. To run all tests in the
+instrumented test directory, select the directory then right-click and press
+<strong>Run tests</strong>.
+</li>
+</ol>
+
+<p>Android Studio displays the results of the instrumented test execution in the
+<strong>Run</strong> window.</p>
+
+<p>To run your instrumented tests from the command-line via Gradle, call the
+ {@code connectedAndroidTest} (or {@code cAT}) task:</p>
+
+<pre>
+./gradlew cAT
+</pre>
+
+<p>You can find the generated HTML test result reports in the
+{@code <path_to_your_project>/app/build/outputs/reports/androidTests/connected/} directory,
+and the corresponding XML files in the
+{@code <path_to_your_project>/app/build/outputs/androidTest-results/connected/} directory.</p>
\ No newline at end of file
diff --git a/docs/html/training/testing/ui-testing/espresso-testing.jd b/docs/html/training/testing/ui-testing/espresso-testing.jd
index 72689ff..45a4ceb 100644
--- a/docs/html/training/testing/ui-testing/espresso-testing.jd
+++ b/docs/html/training/testing/ui-testing/espresso-testing.jd
@@ -55,6 +55,8 @@
<a href="https://github.com/googlesamples/android-testing"
class="external-link">Espresso Code Samples</a>
</li>
+ <li><a href="https://www.code-labs.io/codelabs/android-testing/index.html?index=..%2F..%2Findex#0"
+ class="external-link">Android Testing Codelab</a></li>
</ul>
</div>
</div>
@@ -90,75 +92,51 @@
Set Up Espresso
</h2>
- <p>
- Before you begin using Espresso, you must:
- </p>
+<p>Before building your UI test with Espresso, make sure to configure your test source code
+location and project dependencies, as described in
+<a href="{@docRoot}training/testing/start/index.html#config-instrumented-tests">
+Getting Started with Testing</a>.</p>
- <ul>
- <li>
- <strong>Install the Android Testing Support Library</strong>. The Espresso API is
- located under the {@code com.android.support.test.espresso} package. These classes allow
- you to create tests that use the Espresso testing framework. To learn how to install the
- library, see <a href="{@docRoot}tools/testing-support-library/index.html#setup">
- Testing Support Library Setup</a>.
- </li>
+<p>In the {@code build.gradle} file of your Android app module, you must set a dependency
+ reference to the Espresso library:</p>
- <li>
- <strong>Set up your project structure.</strong> In your Gradle project, the source code for
- the target app that you want to test is typically placed under the {@code app/src/main}
- folder. The source code for instrumentation tests, including
- your Espresso tests, must be placed under the <code>app/src/androidTest</code> folder. To
- learn more about setting up your project directory, see
- <a href="{@docRoot}tools/projects/index.html">Managing Projects</a>.
- </li>
-
- <li>
- <strong>Specify your Android testing dependencies</strong>. In order for the
- <a href="{@docRoot}tools/building/plugin-for-gradle.html">Android Plug-in for Gradle</a> to
- correctly build and run your Espresso tests, you must specify the following libraries in
- the {@code build.gradle} file of your Android app module:
-
- <pre>
+<pre>
dependencies {
- androidTestCompile 'com.android.support:support-annotations:23.0.1'
- androidTestCompile 'com.android.support.test:runner:0.4.1'
- androidTestCompile 'com.android.support.test:rules:0.4.1'
+ ...
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.1'
- // Set this dependency if you want to use Hamcrest matching
- androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
}
</pre>
- </li>
- <li>
- <strong>Turn off animations on your test device.</strong> Leaving system animations turned
- on in the test device might cause unexpected results or may lead your test to fail. Turn
- off animations from <em>Settings</em> by opening <em>Developing Options</em> and
- turning all the following options off:
+<p>Turn off animations on your test device — leaving system animations turned on in the test
+device might cause unexpected results or may lead your test to fail. Turn off animations from
+<em>Settings</em> by opening <em>Developing Options</em> and turning all the following options off:
+</p>
<ul>
<li>
- <em>Window animation scale</em>
+ <strong>Window animation scale</strong>
</li>
<li>
- <em>Transition animation scale</em>
+ <strong>Transition animation scale</strong>
</li>
<li>
- <em>Animator duration scale</em>
+ <strong>Animator duration scale</strong>
</li>
</ul>
</li>
</ul>
+<p>If you want to set up your project to use Espresso features other than what the core API
+ provides, see this
+ <a href="https://google.github.io/android-testing-support-library/docs/espresso/index.html"
+ class="external-link">resource</a>.</p>
<h2 id="build">
Create an Espresso Test Class
</h2>
<p>
- To create an Espresso test, create a Java class or an
- {@link android.test.ActivityInstrumentationTestCase2}
- subclass that follows this programming model:
+ To create an Espresso test, create a Java class that follows this programming model:
</p>
<ol>
@@ -203,11 +181,70 @@
.perform(click()) // click() is a ViewAction
.check(matches(isDisplayed())); // matches(isDisplayed()) is a ViewAssertion
</pre>
+<h3 id="espresso-atr">Using Espresso with ActivityTestRule</h3>
+<p>
+The following section describes how to create a new Espresso test in the JUnit 4 style and use
+<a href="{@docRoot}reference/android/support/test/rule/ActivityTestRule.html">
+{@code ActivityTestRule}</a> to reduce the amount of boilerplate code you need to write. By using
+<a href="{@docRoot}reference/android/support/test/rule/ActivityTestRule.html">
+{@code ActivityTestRule}</a>, the testing framework launches the activity under test
+before each test method annotated with {@code @Test} and before any method annotated with
+{@code @Before}. The framework handles shutting down the activity after the test finishes
+and all methods annotated with {@code @After} are run.</p>
+
+<pre>
+package com.example.android.testing.espresso.BasicSample;
+
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+
+import android.support.test.rule.ActivityTestRule;
+import android.support.test.runner.AndroidJUnit4;
+...
+
+@RunWith(AndroidJUnit4.class)
+@LargeTest
+public class ChangeTextBehaviorTest {
+
+ private String mStringToBetyped;
+
+ @Rule
+ public ActivityTestRule<MainActivity> mActivityRule = new ActivityTestRule<>(
+ MainActivity.class);
+
+ @Before
+ public void initValidString() {
+ // Specify a valid string.
+ mStringToBetyped = "Espresso";
+ }
+
+ @Test
+ public void changeText_sameActivity() {
+ // Type text and then press the button.
+ onView(withId(R.id.editTextUserInput))
+ .perform(typeText(mStringToBetyped), closeSoftKeyboard());
+ onView(withId(R.id.changeTextBt)).perform(click());
+
+ // Check that the text was changed.
+ onView(withId(R.id.textToBeChanged))
+ .check(matches(withText(mStringToBetyped)));
+ }
+}
+</pre>
<h3 id="espresso-aitc2">
Using Espresso with ActivityInstrumentationTestCase2
</h3>
-
+<p>The following section describes how to migrate to Espresso if you have existing test classes
+subclassed from {@link android.test.ActivityInstrumentationTestCase2} and you don't want to rewrite
+them to use JUnit4.</p>
+<p class="note"><strong>Note:</strong> For new UI tests, we strongly recommend that you write your
+test in the JUnit 4 style and use the
+<a href="{@docRoot}reference/android/support/test/rule/ActivityTestRule.html">
+{@code ActivityTestRule}</a> class, instead of
+{@link android.test.ActivityInstrumentationTestCase2}.</p>
<p>
If you are subclassing {@link android.test.ActivityInstrumentationTestCase2}
to create your Espresso test class, you must inject an
@@ -544,40 +581,13 @@
</pre>
<h2 id="run">Run Espresso Tests on a Device or Emulator</h2>
-
- <p>
- To run Espresso tests, you must use the
- <a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">{@code AndroidJUnitRunner}</a>
- class provided in the
- <a href="{@docRoot}tools/testing-support-library/index.html">
- Android Testing Support Library</a> as your default test runner. The
- <a href="{@docRoot}tools/building/plugin-for-gradle.html">Android Plug-in for
- Gradle</a> provides a default directory ({@code src/androidTest/java}) for you to store the
- instrumented test classes and test suites that you want to run on a device. The
- plug-in compiles the test code in that directory and then executes the test app using
- the configured test runner class.
- </p>
-
- <p>
- To run Espresso tests in your Gradle project:
- </p>
-
- <ol>
- <li>Specify
- <a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">{@code AndroidJUnitRunner}</a>
- as the default test instrumentation runner in
- your {@code build.gradle} file:
-
- <pre>
-android {
- defaultConfig {
- testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
- }
-}</pre>
- </li>
- <li>Run your tests from the command-line by calling the the {@code connectedAndroidTest}
- (or {@code cAT}) task:
- <pre>
-./gradlew cAT</pre>
- </li>
- </ol>
+<p>
+You can run Espresso tests from <a href="{@docRoot}sdk/index.html">Android Studio</a> or
+from the command-line. Make sure to specify
+<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+ {@code AndroidJUnitRunner}</a> as the default instrumentation runner in your project.
+</p>
+<p>
+To run your Espresso test, follow the steps for running instrumented tests
+described in <a href="{@docRoot}training/testing/start/index.html#run-instrumented-tests">
+Getting Started with Testing</a>.</p>
diff --git a/docs/html/training/testing/ui-testing/index.jd b/docs/html/training/testing/ui-testing/index.jd
index d660c60..1aa95a4 100644
--- a/docs/html/training/testing/ui-testing/index.jd
+++ b/docs/html/training/testing/ui-testing/index.jd
@@ -1,5 +1,6 @@
page.title=Automating User Interface Tests
page.tags=testing
+page.image=images/testing/UIAutomatorViewer.png
trainingnavtop=true
startpage=true
diff --git a/docs/html/training/testing/ui-testing/uiautomator-testing.jd b/docs/html/training/testing/ui-testing/uiautomator-testing.jd
index ea15d8b..5dca40b 100644
--- a/docs/html/training/testing/ui-testing/uiautomator-testing.jd
+++ b/docs/html/training/testing/ui-testing/uiautomator-testing.jd
@@ -61,43 +61,21 @@
</p>
<h2 id="setup">Set Up UI Automator</h2>
-<p>Before you begin using UI Automator, you must:</p>
- <ul>
- <li>
- <strong>Install the Android Testing Support Library</strong>. The UI Automator API is
- located under the {@code com.android.support.test.uiautomator} package. These classes allow
- you to create tests that use the Espresso testing framework. To learn how to install the
- library, see <a href="{@docRoot}tools/testing-support-library/index.html#setup">
- Testing Support Library Setup</a>.
- </li>
+<p>Before building your UI test with UI Automator, make sure to configure your test source code
+location and project dependencies, as described in
+<a href="{@docRoot}training/testing/start/index.html#config-instrumented-tests">
+Getting Started with Testing</a>.</p>
- <li>
- <strong>Set up your project structure.</strong> In your Gradle project, the source code for
- the target app that you want to test is typically placed under the {@code app/src/main}
- folder. The source code for instrumentation tests, including
- your UI Automator tests, must be placed under the <code>app/src/androidTest</code> folder.
- To learn more about setting up your project directory, see
- <a href="{@docRoot}tools/projects/index.html">Managing Projects</a>.
- </li>
+<p>In the {@code build.gradle} file of your Android app module, you must set a dependency
+ reference to the UI Automator library:</p>
- <li>
- <strong>Specify your Android testing dependencies</strong>. In order for the
- <a href="{@docRoot}tools/building/plugin-for-gradle.html">Android Plug-in for Gradle</a> to
- correctly build and run your UI Automator tests, you must specify the following libraries in
- the {@code build.gradle} file of your Android app module:
-
- <pre>
+<pre>
dependencies {
- androidTestCompile 'com.android.support:support-annotations:23.0.1'
- androidTestCompile 'com.android.support.test:runner:0.4.1'
+ ...
androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.1'
- // Set this dependency if you want to use Hamcrest matching
- androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
}
</pre>
- </li>
- </ul>
<p>To optimize your UI Automator testing, you should first inspect the target app’s UI components
and ensure that they are accessible. These optimization tips are described in the next two
@@ -257,14 +235,10 @@
<pre>
import org.junit.Before;
import android.support.test.runner.AndroidJUnit4;
-import android.support.test.InstrumentationRegistry;
import android.support.test.uiautomator.UiDevice;
import android.support.test.uiautomator.By;
import android.support.test.uiautomator.Until;
-import android.content.Context;
-import android.content.Intent;
-import android.content.pm.PackageManager;
-import static org.junit.Assert.assertThat;
+...
@RunWith(AndroidJUnit4.class)
@SdkSuppress(minSdkVersion = 18)
@@ -305,6 +279,10 @@
}
</pre>
+<p>In the example, the {@code @SdkSuppress(minSdkVersion = 18)} statement helps to ensure that
+ tests will only run on devices with Android 4.3 (API level 18) or higher, as required by the
+ UI Automator framework.</p>
+
<p>Use the
<a href="{@docRoot}reference/android/support/test/uiautomator/UiDevice.html#findObject(android.support.test.uiautomator.UiSelector)">{@code findObject()}</a>
method to retrieve a
@@ -533,33 +511,14 @@
</pre>
<h2 id="run">Run UI Automator Tests on a Device or Emulator</h2>
-<p>UI Automator tests are based on the {@link android.app.Instrumentation} class. The
-<a href="https://developer.android.com/tools/building/plugin-for-gradle.html">
- Android Plug-in for Gradle</a>
-provides a default directory ({@code src/androidTest/java}) for you to store the instrumented test
-classes and test suites that you want to run on a device. The plug-in compiles the test
-code in that directory and then executes the test app using a test runner class. You are
-strongly encouraged to use the
-<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">{@code AndroidJUnitRunner}</a>
-class provided in the
-<a href="{@docRoot}tools/testing-support-library/index.html">Android Testing Support Library</a>
-as your default test runner. </p>
-
-<p>To run UI Automator tests in your Gradle project:</p>
-
-<ol>
-<li>Specify
-<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">{@code AndroidJUnitRunner}</a>
-as the default test instrumentation runner in your {@code build.gradle} file:
-<pre>
-android {
- defaultConfig {
- testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
- }
-}</pre>
-</li>
-<li>Run your tests from the command-line by calling the {@code connectedCheck}
- (or {@code cC}) task:
-<pre>./gradlew cC</pre>
-</li>
-</ol>
\ No newline at end of file
+<p>
+You can run UI Automator tests from <a href="{@docRoot}sdk/index.html">Android Studio</a> or
+from the command-line. Make sure to specify
+<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+ {@code AndroidJUnitRunner}</a> as the default instrumentation runner in your project.
+</p>
+<p>
+To run your UI Automator test, follow the steps for running instrumented tests
+described in <a href="{@docRoot}training/testing/start/index.html#run-instrumented-tests">
+Getting Started with Testing</a>.
+</p>
\ No newline at end of file
diff --git a/docs/html/training/testing/unit-testing/index.jd b/docs/html/training/testing/unit-testing/index.jd
index a35ba80..6610761 100644
--- a/docs/html/training/testing/unit-testing/index.jd
+++ b/docs/html/training/testing/unit-testing/index.jd
@@ -1,5 +1,6 @@
page.title=Building Effective Unit Tests
page.tags=testing,androidjunitrunner,junit,unit test
+page.image=images/testing/hwtest_junit_success.png
trainingnavtop=true
startpage=true
diff --git a/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd b/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd
index db4cc8c..38321ee 100644
--- a/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd
+++ b/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd
@@ -13,6 +13,7 @@
<li>Android 2.2 (API level 8) or higher</li>
<li><a href="{@docRoot}tools/testing-support-library/index.html">
Android Testing Support Library</a></li>
+ <li><a href="{@docRoot}tools/studio/index.html">Android Studio (latest version)</a>.</li>
</ul>
<h2>This lesson teaches you to</h2>
@@ -29,6 +30,8 @@
<li>
<a href="https://github.com/googlesamples/android-testing/tree/master/unit/BasicUnitAndroidTest"
class="external-link">Instrumented Unit Tests Code Samples</a></li>
+ <li><a href="https://www.code-labs.io/codelabs/android-studio-testing/index.html?index=..%2F..%2Findex#0"
+class="external-link">Unit and UI Testing in Android Studio (codelab)</a></li>
</ul>
</div>
</div>
@@ -46,45 +49,10 @@
</p>
<h2 id="setup">Set Up Your Testing Environment</h2>
-<p>Before building instrumented unit tests, you must:</p>
-
- <ul>
- <li>
- <strong>Install the Android Testing Support Library</strong>. The
- <a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
- {@code AndroidJUnitRunner}</a> API, located under the
- {@code com.android.support.test.runner} package, allows you to
- create and run instrumented unit tests. To learn how to install the
- library, see <a href="{@docRoot}tools/testing-support-library/index.html#setup">
- Testing Support Library Setup</a>.
- </li>
-
- <li>
- <strong>Set up your project structure.</strong> In your Gradle project, the source code for
- the target app that you want to test is typically placed under the {@code app/src/main/java}
- folder. The source code for instrumentatation tests, including your unit tests, must be
- placed under the <code>app/src/androidTest/java</code> folder.
- To learn more about setting up your project directory, see
- <a href="{@docRoot}tools/projects/index.html">Managing Projects</a>.
- </li>
-
- <li>
- <strong>Specify your Android testing dependencies</strong>. In order for the
- <a href="{@docRoot}tools/building/plugin-for-gradle.html">Android Plug-in for Gradle</a> to
- correctly build and run your instrumented unit tests, you must specify the following
- libraries in the {@code build.gradle} file of your Android app module:
-
- <pre>
-dependencies {
- androidTestCompile 'com.android.support:support-annotations:23.0.1'
- androidTestCompile 'com.android.support.test:runner:0.4.1'
- androidTestCompile 'com.android.support.test:rules:0.4.1'
- // Set this dependency if you want to use Hamcrest matching
- androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
-}
-</pre>
- </li>
- </ul>
+<p>Before building your instrumented unit test, make sure to configure your test source code
+location and project dependencies, as described in
+<a href="{@docRoot}training/testing/start/index.html#config-instrumented-tests">
+Getting Started with Testing</a>.</p>
<h2 id="build">Create an Instrumented Unit Test Class</h2>
<p>
@@ -97,8 +65,8 @@
<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
{@code AndroidJUnitRunner}</a> class
provided in the Android Testing Support Library as your default test runner. This step is described
-in more detail in <a href="#run">Run Instrumented Unit Tests</a>.
-</p>
+in more detail in <a href="{@docRoot}training/testing/start/index.html#run-instrumented-tests">
+Getting Started with Testing</p>
<p>The following example shows how you might write an instrumented unit test to test that
the {@link android.os.Parcelable} interface is implemented correctly for the
@@ -115,6 +83,7 @@
import static org.junit.Assert.assertThat;
@RunWith(AndroidJUnit4.class)
+@SmallTest
public class LogHistoryAndroidUnitTest {
public static final String TEST_STRING = "This is a string";
@@ -195,57 +164,7 @@
<h2 id="run">Run Instrumented Unit Tests</h2>
<p>
-The
-<a href="https://developer.android.com/tools/building/plugin-for-gradle.html">
- Android Plug-in for Gradle</a>
-provides a default directory ({@code src/androidTest/java}) for you to store the instrumented unit
-and integration test classes and test suites that you want to run on a device. The plug-in compiles
-the test code in that directory and then executes the test app using a test runner class. You must
-set the
-<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
-{@code AndroidJUnitRunner}</a> class provided in the
-<a href="{@docRoot}tools/testing-support-library/index.html">Android Testing Support Library</a>
-as your default test runner.</p>
-</p>
-
-<p>To specify
-<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
-{@code AndroidJUnitRunner}</a> as the default test instrumentation runner, add the following
-setting in your {@code build.gradle} file:</p>
-<pre>
-android {
- defaultConfig {
- testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
- }
-}
-</pre>
-
-<h3 id="run-from-Android-Studio">Running instrumented unit tests from Android Studio</h3>
-<p>
-To run instrumented unit tests in your Gradle project from Android Studio:
-</p>
-<ol>
-<li>Open the <strong>Build Variants</strong> window by clicking the left-hand tab, then set the
-test artifact to <em>Android Instrumentation Tests</em>.
-</li>
-<li>In the <strong>Project</strong> window, drill down to your unit test class or method, then
- right-click and run it using the Android Test configuration.
-</li>
-</ol>
-
-<p>Android Studio displays the results of the unit test execution in the <strong>Run</strong>
-window.</p>
-
-<h3 id="run-from-commandline">Running instrumented unit tests from the command-line</h3>
-
-<p>To run instrumented unit tests in your Gradle project from the command-line, call the
- {@code connectedCheck} (or {@code cC}) task:</p>
-
-<pre>
-./gradlew cC
-</pre>
-
-<p>You can find the generated HTML test result reports in the
-{@code <path_to_your_project>/app/build/outputs/reports/androidTests/connected/} directory,
-and the corresponding XML files in the
-{@code <path_to_your_project>/app/build/outputs/androidTest-results/connected/} directory.</p>
\ No newline at end of file
+To run your test, follow the steps for running instrumented tests
+described in <a href="{@docRoot}training/testing/start/index.html#run-instrumented-tests">
+Getting Started with Testing</a>.
+</p>
\ No newline at end of file
diff --git a/docs/html/training/testing/unit-testing/local-unit-tests.jd b/docs/html/training/testing/unit-testing/local-unit-tests.jd
index 98939fa..893d957 100644
--- a/docs/html/training/testing/unit-testing/local-unit-tests.jd
+++ b/docs/html/training/testing/unit-testing/local-unit-tests.jd
@@ -10,7 +10,7 @@
<h2>Dependencies and Prerequisites</h2>
<ul>
- <li>Android Plug-in for Gradle 1.1.0 or higher</li>
+ <li><a href="{@docRoot}tools/studio/index.html">Android Studio (latest version)</a>.</li>
</ul>
<h2>This lesson teaches you to</h2>
@@ -27,6 +27,8 @@
<li>
<a href="https://github.com/googlesamples/android-testing/tree/master/unit/BasicSample"
class="external-link">Local Unit Tests Code Samples</a></li>
+ <li><a href="https://codelabs.developers.google.com/codelabs/android-testing/index.html?index=..%2F..%2Findex#0"
+class="external-link">Android Testing Codelab</a></li>
</ul>
</div>
</div>
@@ -36,47 +38,15 @@
you avoid the overhead of loading the target app and unit test code onto a physical device or
emulator every time your test is run. Consequently, the execution time for running your unit
test is greatly reduced. With this approach, you normally use a mocking framework, like
-<a href="https://code.google.com/p/mockito/" class="external-link">Mockito</a>, to fulfill any
+<a href="https://github.com/mockito/mockito" class="external-link">Mockito</a>, to fulfill any
dependency relationships.</p>
-<p><a href="{@docRoot}tools/building/plugin-for-gradle.html">Android Plug-in for Gradle</a>
-version 1.1.0 and higher allows you to create a source directory ({@code src/test/java}) in your
-project to store JUnit tests that you want to run on a local machine. This feature improves your
-project organization by letting you group your unit tests together into a single source set. You
-can run the tests from Android Studio or the command-line, and the plugin executes them on the
-local Java Virtual Machine (JVM) on your development machine. </p>
-
<h2 id="setup">Set Up Your Testing Environment</h2>
-<p>Before building local unit tests, you must:</p>
+<p>Before building your local unit test, make sure to configure your test source code location and
+project dependencies, as described in
+<a href="{@docRoot}training/testing/start/index.html#config-local-tests">
+Getting Started with Testing</a>.</p>
- <ul>
- <li>
- <strong>Set up your project structure.</strong> In your Gradle project, the source code for
- the target app that you want to test is typically placed under the {@code app/src/main/java}
- folder. The source code for your local unit tests must be placed under the
- <code>app/src/test/java</code> folder.
- To learn more about setting up your project directory, see
- <a href="#run">Run Local Unit Tests</a> and
- <a href="{@docRoot}tools/projects/index.html">Managing Projects</a>.
- </li>
-
- <li>
- <strong>Specify your Android testing dependencies</strong>. In order to use JUnit 4 and
- Mockito with your local unit tests, specify the following libraries in
- the {@code build.gradle} file of your Android app module:
-
- <pre>
-dependencies {
- // Unit testing dependencies
- testCompile 'junit:junit:4.12'
- // Set this dependency if you want to use Mockito
- testCompile 'org.mockito:mockito-core:1.10.19'
- // Set this dependency if you want to use Hamcrest matching
- testCompile 'org.hamcrest:hamcrest-library:1.1'
-}
-</pre>
- </li>
- </ul>
<h2 id="build">Create a Local Unit Test Class</h2>
<p>Your local unit test class should be written as a JUnit 4 test class.
@@ -116,44 +86,10 @@
<a href="http://junit.org/javadoc/latest/org/junit/Assert.html" class="external-link">
junit.Assert</a> methods to perform validation checks (or <em>assertions</em>) to compare the state
of the component under test against some expected value. To make tests more readable, you
-can use <a href="https://code.google.com/p/hamcrest/wiki/Tutorial" class="external-link">
+can use <a href="https://github.com/hamcrest" class="external-link">
Hamcrest matchers</a> (such as the {@code is()} and {@code equalTo()} methods) to match the
returned result against the expected result.</p>
-<p>In your JUnit 4 test class, you can use annotations to call out sections in your test code for
-special processing, such as:</p>
-
-<ul>
-<li>
-{@code @Before}: Use this annotation to specify a block of code with test setup operations. This
-code block will be invoked before each test. You can have multiple {@code @Before} methods but
-the order which these methods are called is not fixed.
-</li>
-<li>
-{@code @After}: This annotation specifies a block of code with test tear-down operations. This
-code block will be called after every test method. You can define multiple {@code @After}
-operations in your test code. Use this annotation to release any resources from memory.
-</li>
-<li>
-{@code @Test}: Use this annotation to mark a test method. A single test class can contain
-multiple test methods, each prefixed with this annotation.
-</li>
-<li>
-{@code @BeforeClass}: Use this annotation to specify static methods to be invoked only once per
-test class. This testing step is useful for expensive operations such as connecting to a database.
-</li>
-<li>
-{@code @AfterClass}: Use this annotation to specify static methods to be invoked only after all
-tests in the class have been run. This testing step is useful for releasing any resources allocated
-in the {@code @BeforeClass} block.
-</li>
-<li>
-{@code @Test(timeout=<milliseconds>)}: Specifies a timeout period for the test. If the
-test starts but does not complete within the given timeout period, it automatically fails. You must
-specify the timeout period in milliseconds, for example: {@code @Test(timeout=5000)}.
-</li>
-</ul>
-
<h3 id="mocking-dependencies">Mocking Android dependencies</h3>
<p>
By default, the <a href="{@docRoot}tools/building/plugin-for-gradle.html">
@@ -166,7 +102,7 @@
your component interacts with a dependency in an expected way. By substituting Android dependencies
with mock objects, you can isolate your unit test from the rest of the Android system while
verifying that the correct methods in those dependencies are called. The
-<a href="https://code.google.com/p/mockito/" class="external-link">Mockito</a> mocking framework
+<a href="https://github.com/mockito/mockito" class="external-link">Mockito</a> mocking framework
for Java (version 1.9.5 and higher) offers compatibility with Android unit testing.
With Mockito, you can configure mock objects to return some specific value when invoked.</p>
@@ -240,63 +176,8 @@
<h2 id="run">Run Local Unit Tests</h2>
<p>
-The Android Plug-in for Gradle provides a default directory ({@code src/test/java}) for you to
-store unit test classes that you want to run on a local JVM. The plug-in compiles the test code in
-that directory and then executes the test app locally using the default test runner class.
+To run your tests, follow the steps for running local unit tests
+described in <a href="{@docRoot}training/testing/start/index.html#run-local-tests">
+Getting Started with Testing</a>.
</p>
-<p>
-As with production code, you can create unit tests for a
-<a href="http://developer.android.com/tools/building/configuring-gradle.html#workBuildVariants"
-class="external-link">specific flavor or build type</a>. You should keep unit tests in a test
-source tree location that corresponds to your production source tree, such as:
-<table>
-<tr>
-<th>Path to Production Class</th>
-<th>Path to Local Unit Test Class</th>
-</tr>
-<tr>
-<td>{@code src/main/java/Foo.java}</td>
-<td>{@code src/test/java/FooTest.java}</td>
-</tr>
-<tr>
-<td>{@code src/debug/java/Foo.java}</td>
-<td>{@code src/testDebug/java/FooTest.java}</td>
-</tr>
-<tr>
-<td>{@code src/myFlavor/java/Foo.java}</td>
-<td>{@code src/testMyFlavor/java/FooTest.java}</td>
-</tr>
-</table>
-
-<h3 id="run-from-Android-Studio">Running local unit tests from Android Studio</h3>
-<p>
-To run local unit tests in your Gradle project from Android Studio:
-</p>
-<ol>
-<li>In the <strong>Project</strong> window, right click on the project and synchronize your project.
-</li>
-<li>Open the <strong>Build Variants</strong> window by clicking the left-hand tab, then change the
-test artifact to <em>Unit Tests</em>.
-</li>
-<li>In the <strong>Project</strong> window, drill down to your unit test class or method, then
-right-click and run it.
-</li>
-</ol>
-
-<p>Android Studio displays the results of the unit test execution in the <strong>Run</strong>
-window.</p>
-
-<h3 id="run-from-commandline">Running local unit tests from the command-line</h3>
-
-<p>To run local unit tests in your Gradle project from the command-line, call the {@code test} task
-command with the {@code --continue} option.</p>
-
-<pre>
-./gradlew test --continue
-</pre>
-
-<p>If there are failing tests, the command will display links to HTML reports (one per build
-variant). You can find the generated HTML test result reports in the
-{@code <path_to_your_project>/app/build/reports/tests/} directory, and the corresponding XML
-files in the {@code <path_to_your_project>/app/build/test-results/} directory.</p>