When you test an element or system of elements you do it in *isolation*. For
example, to test a ViewModel you don't need to start an emulator and launch a UI
because it doesn't (or shouldn't) depend on the Android framework.

However, the subject under test might *depend* on others for it to work. For
instance, a ViewModel might depend on a data repository to work.

When you need to provide a dependency to a subject under test, a common practice
is to create a *test double* (or *test object*). Test doubles are objects that
look and act as components in your app but they're created in your test to
provide a specific behavior or data. The main advantages are that they make your
tests faster and simpler.

## Types of test doubles

There are various types of test doubles:

| Fake | A test double that has a "working" implementation of the class, but it is implemented in a way that makes it good for tests but unsuitable for production. Example: an in-memory database. Fakes don't require a mocking framework and are lightweight. They are **preferred**. |
| Mock | A test double that behaves how you program it to behave and that has expectations about its interactions. Mocks will fail tests if their interactions don't match the requirements that you define. Mocks are usually created with a *mocking framework* to achieve all this. Example: Verify that a method in a database was called exactly once. |
| Stub | A test double that behaves how you program it to behave but doesn't have expectations about its interactions. Usually created with a mocking framework. Fakes are preferred over stubs for simplicity. |
| Dummy | A test double that is passed around but not used, such as if you just need to provide it as a parameter. Example: an empty function passed as a click callback. |
| Spy | A wrapper over a real object which also keeps track of some additional information, similar to mocks. They are usually avoided for adding complexity. Fakes or mocks are therefore preferred over spies. |
| Shadow | Fake used in Robolectric. |
|---|---|

| **Caution:** There are conflicting definitions depending on the source. A comprehensive source is [*Mocks aren't Stubs*](https://martinfowler.com/articles/mocksArentStubs.html) by Martin Fowler.
| **Note:** When using a library or framework, check with the authors to see if they provide any officially-supported testing infrastructures, such as fakes, that you can reliably depend on.

## Example using a fake

Suppose that you want to unit test a ViewModel that depends on an interface
called `UserRepository` and exposes the name of the first user to a UI. You can
create a fake test double by implementing the interface and returning known
data.  

    object FakeUserRepository : UserRepository {
        fun getUsers() = listOf(UserAlice, UserBob)
    }

    val const UserAlice = User("Alice")
    val const UserBob = User("Bob")

This fake `UserRepository` does not need to depend on the local and remote data
sources that the production version would use. The file lives in the test source
set and will not ship with the production app.
![A fake dependency can return known data without depending on remote data sources](https://developer.android.com/static/training/testing/fundamentals/fake-deps.png) **Figure 1**: A fake dependency in a unit test.

The following test verifies that the ViewModel correctly exposes the first user
name to the view.  

    @Test
    fun viewModelA_loadsUsers_showsFirstUser() {
        // Given a VM using fake data
        val viewModel = ViewModelA(FakeUserRepository) // Kicks off data load on init

        // Verify that the exposed data is correct
        assertEquals(viewModel.firstUserName, UserAlice.name)
    }

Replacing the `UserRepository` with a fake is easy in a unit test, because the
ViewModel is created by the tester. However, it can be challenging to replace
arbitrary elements in bigger tests.

## Replacing components and dependency injection

When tests have no control over the creation of the systems under test,
replacing components for test doubles becomes more involved and requires the
architecture of your app to follow a *testable* design.

Even big end-to-end tests can benefit from using test doubles, such as an
instrumented UI test that navigates through a full user flow in your app. In
that case you might want to make your test *hermetic*. A hermetic test avoids
all external dependencies, such as fetching data from the internet. This
improves reliability and performance.
![](https://developer.android.com/static/training/testing/fundamentals/bigtest.png) **Figure 2**: A big test that covers most of the app and fakes remote data.

You can design your app to achieve this flexibility manually, but we recommend
using a [dependency injection](https://developer.android.com/training/dependency-injection) framework like [Hilt](https://developer.android.com/training/dependency-injection/hilt-android) to replace components
in your app at test time. See the [Hilt testing guide.](https://developer.android.com/training/dependency-injection/hilt-testing)
| **Note:** On Android, you can also use the [Robolectric](https://developer.android.com/training/testing/local-tests/robolectric) framework, which provides a special type of test double, called shadows.

## Next steps

The [Testing strategies](https://developer.android.com/training/testing/fundamentals/strategies) page shows how you can improve your productivity
using different types of tests.