am d43ec638: am 174dc3ba: Merge "docs: Added training docs for Android unit testing tools and APIs. This training covers techniques for running unit tests on local machines, using mock objects in local unit tests, and building instrumented unit tests to run on a devic

* commit 'd43ec6380ce04f4c0830cd35d1dbd7b3050799d4':
  docs: Added training docs for Android unit testing tools and APIs. This training covers techniques for running unit tests on local machines, using mock objects in local unit tests, and building instrumented unit tests to run on a device or emulator.

5 files changed, 634 insertions, 1 deletions

diff --git a/docs/html/training/testing/ui-testing/index.jd b/docs/html/training/testing/ui-testing/index.jd
index 20422f7..d660c60 100644
--- a/docs/html/training/testing/ui-testing/index.jd
+++ b/docs/html/training/testing/ui-testing/index.jd
@@ -72,5 +72,5 @@ Testing UI for a Single App</a></strong></dt>
     <dd>Learn how to test UI in a single app by using the Espresso testing framework.</dd>
   <dt><strong><a href="uiautomator-testing.html">
 Testing UI for Multiple Apps</a></strong></dt>
-    <dd>Learn how to test UI in multiple apps by using the UI Automator testing framework</dd>
+    <dd>Learn how to test UI in multiple apps by using the UI Automator testing framework.</dd>
 </dl>
\ 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
new file mode 100644
index 0000000..a35ba80
--- /dev/null
+++ b/docs/html/training/testing/unit-testing/index.jd
@@ -0,0 +1,63 @@
+page.title=Building Effective Unit Tests
+page.tags=testing,androidjunitrunner,junit,unit test
+
+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>Unit tests are the fundamental tests in your app testing strategy. By creating and running unit
+tests against your code, you can easily verify that the logic of individual units is correct.
+Running unit tests after every build helps you to
+quickly catch and fix software regressions introduced by code changes to your app.
+</p>
+
+<p>A unit test generally exercises the functionality of the smallest possible unit of code (which
+could be a method, class, or component) in a repeatable way. You should build unit tests when you
+need to verify the logic of specific code in your app. For example, if you are unit testing a
+class, your test might check that the class is in the right state. Typically, the unit of code
+is tested in isolation; your test affects and monitors changes to that unit only. A
+<a href="http://en.wikipedia.org/wiki/Mock_object" class="external-link">mocking framework</a>
+can be used to isolate your unit from its dependencies.</p>
+
+<p class="note"><strong>Note:</strong> Unit tests are not suitable for testing
+complex UI interaction events. Instead, you should use the UI testing frameworks, as described in
+<a href="{@docRoot}training/testing/ui-testing/index.html">Automating UI Tests</a>.</p>
+
+<p>For testing Android apps, you typically create these types of automated unit tests:</p>
+
+<ul>
+<li><strong>Local tests:</strong> Unit tests that run on your local machine only. These tests are
+compiled to run locally on the Java Virtual Machine (JVM) to minimize execution time. Use this
+approach to run unit tests that have no dependencies on the Android framework or have dependencies
+that can be filled by using mock objects.</li>
+<li><strong>Instrumented tests:</strong> Unit tests that run on an Android device or emulator.
+These tests have access to instrumentation information, such as the
+{@link android.content.Context} for the app under test. Use this approach to run unit tests that
+have Android dependencies which cannot be easily filled by using mock objects.</li>
+</ul>
+
+<p>The lessons in this class teach you how to build these types of automated unit tests.</p>
+
+<h2>Lessons</h2>
+<dl>
+  <dt><strong><a href="local-unit-tests.html">
+Building Local Unit Tests</a></strong></dt>
+    <dd>Learn how to build unit tests that run on your local machine.</dd>
+  <dt><strong><a href="instrumented-unit-tests.html">
+Building Instrumented Unit Tests</a></strong></dt>
+    <dd>Learn how to build unit tests that run on an Android device or emulator.</dd>
+</dl>
\ No newline at end of file
diff --git a/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd b/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd
new file mode 100644
index 0000000..07f0f73
--- /dev/null
+++ b/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd
@@ -0,0 +1,250 @@
+page.title=Building Instrumented Unit Tests
+page.tags=testing,androidjunitrunner,junit,unit test,mock,instrumentation
+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>
+  </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 a Instrumented Unit Test Class</a></li>
+    <li><a href="#run">Run Instrumented Unit Tests</a></li>
+  </ol>
+
+  <h2>Try it out</h2>
+
+  <ul>
+    <li>
+<a href="https://github.com/googlesamples/android-testing/tree/master/unittesting/BasicUnitAndroidTest"
+class="external-link">Instrumented Unit Tests Code Samples</a></li>
+  </ul>
+</div>
+</div>
+
+<p>
+Instrumented unit tests are unit tests that run on physical devices and emulators, instead of
+the Java Virtual Machine (JVM) on your local machine. You should create instrumented unit tests
+if your tests need access to instrumentation information (such as the target app's
+{@link android.content.Context}) or if they require the real implementation of an Android framework
+component (such as a {@link android.os.Parcelable} or {@link android.content.SharedPreferences}
+object). Using instrumented unit tests also helps to reduce the effort required to write and
+maintain mock code. You are still free to use a mocking framework, if you choose, to simulate any
+dependency relationships. Instrumented unit tests can take advantage of the Android framework APIs
+and supporting APIs, such as the Android Testing Support Library.
+</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.test:runner:0.2'
+    androidTestCompile 'com.android.support.test:rules:0.2'
+    // Set this dependency if you want to use Hamcrest matching
+    androidTestCompile 'org.hamcrest:hamcrest-library:1.1'
+}
+</pre>
+      </li>
+  </ul>
+
+<h2 id="build">Create an Instrumented Unit Test Class</h2>
+<p>
+Your instrumented unit test class should be written as a JUnit 4 test class. To learn more about
+creating JUnit 4 test classes and using JUnit 4 assertions and annotations, see
+<a href="local-unit-tests.html#build">Create a Local Unit Test Class</a>.
+</p>
+<p>To create an instrumented JUnit 4 test class, add the {@code &#64;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
+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>
+
+<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
+{@code LogHistory} class:</p>
+
+<pre>
+import android.os.Parcel;
+import android.support.test.runner.AndroidJUnit4;
+import android.util.Pair;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import java.util.List;
+import static org.hamcrest.Matchers.is;
+import static org.junit.Assert.assertThat;
+
+&#64;RunWith(AndroidJUnit4.class)
+public class LogHistoryAndroidUnitTest {
+
+    public static final String TEST_STRING = "This is a string";
+    public static final long TEST_LONG = 12345678L;
+    private LogHistory mLogHistory;
+
+    &#64;Before
+    public void createLogHistory() {
+        mLogHistory = new LogHistory();
+    }
+
+    &#64;Test
+    public void logHistory_ParcelableWriteRead() {
+        // Set up the Parcelable object to send and receive.
+        mLogHistory.addEntry(TEST_STRING, TEST_LONG);
+
+        // Write the data.
+        Parcel parcel = Parcel.obtain();
+        mLogHistory.writeToParcel(parcel, mLogHistory.describeContents());
+
+        // After you're done with writing, you need to reset the parcel for reading.
+        parcel.setDataPosition(0);
+
+        // Read the data.
+        LogHistory createdFromParcel = LogHistory.CREATOR.createFromParcel(parcel);
+        List&lt;Pair&lt;String, Long&gt;&gt; createdFromParcelData = createdFromParcel.getData();
+
+        // Verify that the received data is correct.
+        assertThat(createdFromParcelData.size(), is(1));
+        assertThat(createdFromParcelData.get(0).first, is(TEST_STRING));
+        assertThat(createdFromParcelData.get(0).second, is(TEST_LONG));
+    }
+}
+</pre>
+
+<h3 id="test-suites">Creating a test suite</h3>
+<p>
+To organize the execution of your instrumented unit tests, you can group a collection of test
+classes in a <em>test suite</em> class and run these tests together. Test suites can be nested;
+your test suite can group other test suites and run all their component test classes together.
+</p>
+
+<p>
+A test suite is contained in a test package, similar to the main application package. By
+convention, the test suite package name usually ends with the {@code .suite} suffix (for example,
+{@code com.example.android.testing.mysample.suite}).
+</p>
+
+<p>
+To create a test suite for your unit tests, import the JUnit
+<a href="http://junit.sourceforge.net/javadoc/org/junit/runner/RunWith.html"
+class="external-link">{@code RunWith}</a> and
+<a href="http://junit.sourceforge.net/javadoc/org/junit/runners/Suite.html"
+class="external-link">{@code Suite}</a> classes. In your test suite, add the
+{@code &#64;RunWith(Suite.class)} and the {@code &#64;Suite.SuitClasses()} annotations. In
+the {@code &#64;Suite.SuiteClasses()} annotation, list the individual test classes or test
+suites as arguments.
+</p>
+
+<p>
+The following example shows how you might implement a test suite called {@code UnitTestSuite}
+that groups and runs the {@code CalculatorInstrumentationTest} and
+{@code CalculatorAddParameterizedTest} test classes together.
+</p>
+
+<pre>
+import com.example.android.testing.mysample.CalculatorAddParameterizedTest;
+import com.example.android.testing.mysample.CalculatorInstrumentationTest;
+import org.junit.runner.RunWith;
+import org.junit.runners.Suite;
+
+// Runs all unit tests.
+&#64;RunWith(Suite.class)
+&#64;Suite.SuiteClasses({CalculatorInstrumentationTest.class,
+        CalculatorAddParameterizedTest.class})
+public class UnitTestSuite {}
+</pre>
+
+<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 &lt;path_to_your_project&gt;/app/build/outputs/reports/androidTests/connected/} directory,
+and the corresponding XML files in the
+{@code &lt;path_to_your_project&gt;/app/build/outputs/androidTest-results/connected/} directory.</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
new file mode 100644
index 0000000..421709b
--- /dev/null
+++ b/docs/html/training/testing/unit-testing/local-unit-tests.jd
@@ -0,0 +1,302 @@
+page.title=Building Local Unit Tests
+page.tags=testing,androidjunitrunner,junit,unit test,mock
+trainingnavtop=true
+
+@jd:body
+
+<!-- This is the training bar -->
+<div id="tb-wrapper">
+<div id="tb">
+  <h2>Dependencies and Prerequisites</h2>
+
+  <ul>
+    <li>Android Plug-in for Gradle 1.1.0 or higher</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 a Local Unit Test Class</a></li>
+    <li><a href="#run">Run Local Unit Tests</a></li>
+  </ol>
+
+  <h2>Try it out</h2>
+
+  <ul>
+    <li>
+<a href="https://github.com/googlesamples/android-testing/tree/master/unittesting/BasicSample"
+class="external-link">Local Unit Tests Code Samples</a></li>
+  </ul>
+</div>
+</div>
+
+<p>If your unit test has no dependencies or only has simple dependencies on Android, you should run
+your test on a local development machine. This testing approach is efficient because it helps
+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
+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>
+
+  <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
+    androidTestCompile '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.
+<a href="http://junit.org/" class="external-link">JUnit</a> is the most popular
+and widely-used unit testing framework for Java. The latest version of this framework, JUnit 4,
+allows you to write tests in a cleaner and more flexible way than its predecessor versions. Unlike
+the previous approach to Android unit testing based on JUnit 3, with JUnit 4, you do not need to
+extend the {@code junit.framework.TestCase} class. You also do not need to prefix your test method
+name with the {@code ‘test’} keyword, or use any classes in the {@code junit.framework} or
+{@code junit.extensions} package.</p>
+
+<p>To create a basic JUnit 4 test class, create a Java class that contains one or more test methods.
+A test method begins with the {@code &#64;Test} annotation and contains the code to exercise
+and verify a single functionality in the component that you want to test.</p>
+
+<p>The following example shows how you might implement a local unit test class. The test method
+{@code emailValidator_CorrectEmailSimple_ReturnsTrue} verifies that the {@code isValidEmail()}
+method in the app under test returns the correct result.</p>
+
+<pre>
+import org.junit.Test;
+import java.util.regex.Pattern;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
+
+public class EmailValidatorTest {
+
+    &#64;Test
+    public void emailValidator_CorrectEmailSimple_ReturnsTrue() {
+        assertThat(EmailValidator.isValidEmail("name&#64;email.com"), is(true));
+    }
+    ...
+}
+</pre>
+
+<p>To test that components in your app return the expected results, use the
+<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">
+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 &#64;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 &#64;Before} methods but
+the order which these methods are called is not fixed.
+</li>
+<li>
+{@code &#64;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 &#64;After}
+operations in your test code. Use this annotation to release any resources from memory.
+</li>
+<li>
+{@code &#64;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 &#64;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 &#64;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 &#64;BeforeClass} block.
+</li>
+<li>
+{@code &#64;Test(timeout=&lt;milliseconds&gt;)}: 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 &#64;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">
+Android Plug-in for Gradle</a> executes your local unit tests against a modified
+version of the {@code android.jar} library, which does not contain any actual code. Instead, method
+calls to Android classes from your unit test throw an exception.
+</p>
+<p>
+You can use a mocking framework to stub out external dependencies in your code, to easily test that
+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
+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>
+
+<p>To add a mock object to your local unit test using this framework, follow this programming model:
+</p>
+
+<ol>
+<li>
+Include the Mockito library dependency in your {@code build.gradle} file, as described in
+<a href="#setup">Set Up Your Testing Environment</a>.
+</li>
+<li>At the beginning of your unit test class definition, add the
+{@code &#64;RunWith(MockitoJUnitRunner.class)} annotation. This annotation tells the Mockito test
+runner to validate that your usage of the framework is correct and simplifies the initialization of
+your mock objects.
+</li>
+<li>To create a mock object for an Android dependency, add the {@code &#64;Mock} annotation before
+the field declaration.</li>
+<li>To stub the behavior of the dependency, you can specify a condition and return
+value when the condition is met by using the {@code when()} and {@code thenReturn()} methods.
+</li>
+</ol>
+
+<p>
+The following example shows how you might create a unit test that uses a mock
+{@link android.content.Context} object.
+</p>
+
+<pre>
+import static org.hamcrest.MatcherAssert.assertThat;
+import static org.hamcrest.CoreMatchers.*;
+import static org.mockito.Mockito.*;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.mockito.Mock;
+import org.mockito.runners.MockitoJUnitRunner;
+import android.content.SharedPreferences;
+
+&#64;RunWith(MockitoJUnitRunner.class)
+public class UnitTestSample {
+
+    private static final String FAKE_STRING = "HELLO WORLD";
+
+    &#64;Mock
+    Context mMockContext;
+
+    &#64;Test
+    public void readStringFromContext_LocalizedString() {
+        // Given a mocked Context injected into the object under test...
+        when(mMockContext.getString(R.string.hello_word))
+                .thenReturn(FAKE_STRING);
+        ClassUnderTest myObjectUnderTest = new ClassUnderTest(mMockContext);
+
+        // ...when the string is returned from the object under test...
+        String result = myObjectUnderTest.getHelloWorldString();
+
+        // ...then the result should be the expected one.
+        assertThat(result, is(FAKE_STRING));
+    }
+}
+</pre>
+
+<p>
+To learn more about using the Mockito framework, see the
+<a href="http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html"
+class="external-link">Mockito API reference</a> and the
+{@code SharedPreferencesHelperTest} class in the
+<a href="https://github.com/googlesamples/android-testing/tree/master/unittesting/BasicSample"
+class="external-link">sample code</a>.
+</p>
+
+<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.
+</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 &lt;path_to_your_project&gt;/app/build/reports/tests/} directory, and the corresponding XML
+files in the {@code &lt;path_to_your_project&gt;/app/build/test-results/} directory.</p>
\ No newline at end of file
diff --git a/docs/html/training/training_toc.cs b/docs/html/training/training_toc.cs
index 862663e..089739b 100644
--- a/docs/html/training/training_toc.cs
+++ b/docs/html/training/training_toc.cs
@@ -1875,6 +1875,24 @@ results."
         </ul>
       </li>
     </ul>
+    <ul>
+      <li class="nav-section">
+      <div class="nav-section-header"><a href="<?cs var:toroot ?>training/testing/unit-testing/index.html"
+         description="How to build effective unit tests for Android apps.">
+            Building Effective Unit Tests
+          </a></div>
+        <ul>
+          <li><a href="<?cs var:toroot ?>training/testing/unit-testing/local-unit-tests.html">
+            <span class="en">Building Local Unit Tests</span>
+            </a>
+          </li>
+          <li><a href="<?cs var:toroot ?>training/testing/unit-testing/instrumented-unit-tests.html">
+            <span class="en">Building Instrumented Unit Tests</span>
+            </a>
+          </li>
+        </ul>
+      </li>
+    </ul>
   </li>
   <!-- End best Testing -->