@TestfunviewModelA_loadsUsers_showsFirstUser(){// Given a VM using fake datavalviewModel=ViewModelA(FakeUserRepository)// Kicks off data load on init// Verify that the exposed data is correctassertEquals(viewModel.firstUserName,UserAlice.name)}
[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],null,["# Use test doubles in Android\n\nWhen you test an element or system of elements you do it in *isolation*. For\nexample, to test a ViewModel you don't need to start an emulator and launch a UI\nbecause it doesn't (or shouldn't) depend on the Android framework.\n\nHowever, the subject under test might *depend* on others for it to work. For\ninstance, a ViewModel might depend on a data repository to work.\n\nWhen you need to provide a dependency to a subject under test, a common practice\nis to create a *test double* (or *test object*). Test doubles are objects that\nlook and act as components in your app but they're created in your test to\nprovide a specific behavior or data. The main advantages are that they make your\ntests faster and simpler.\n\nTypes of test doubles\n---------------------\n\nThere are various types of test doubles:\n\n| 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**. |\n| 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. |\n| 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. |\n| 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. |\n| 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. |\n| Shadow | Fake used in Robolectric. |\n|--------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n\n| **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.\n| **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.\n\nExample using a fake\n--------------------\n\nSuppose that you want to unit test a ViewModel that depends on an interface\ncalled `UserRepository` and exposes the name of the first user to a UI. You can\ncreate a fake test double by implementing the interface and returning known\ndata. \n\n object FakeUserRepository : UserRepository {\n fun getUsers() = listOf(UserAlice, UserBob)\n }\n\n val const UserAlice = User(\"Alice\")\n val const UserBob = User(\"Bob\")\n\nThis fake `UserRepository` does not need to depend on the local and remote data\nsources that the production version would use. The file lives in the test source\nset and will not ship with the production app.\n**Figure 1**: A fake dependency in a unit test.\n\nThe following test verifies that the ViewModel correctly exposes the first user\nname to the view. \n\n @Test\n fun viewModelA_loadsUsers_showsFirstUser() {\n // Given a VM using fake data\n val viewModel = ViewModelA(FakeUserRepository) // Kicks off data load on init\n\n // Verify that the exposed data is correct\n assertEquals(viewModel.firstUserName, UserAlice.name)\n }\n\nReplacing the `UserRepository` with a fake is easy in a unit test, because the\nViewModel is created by the tester. However, it can be challenging to replace\narbitrary elements in bigger tests.\n\nReplacing components and dependency injection\n---------------------------------------------\n\nWhen tests have no control over the creation of the systems under test,\nreplacing components for test doubles becomes more involved and requires the\narchitecture of your app to follow a *testable* design.\n\nEven big end-to-end tests can benefit from using test doubles, such as an\ninstrumented UI test that navigates through a full user flow in your app. In\nthat case you might want to make your test *hermetic*. A hermetic test avoids\nall external dependencies, such as fetching data from the internet. This\nimproves reliability and performance.\n**Figure 2**: A big test that covers most of the app and fakes remote data.\n\nYou can design your app to achieve this flexibility manually, but we recommend\nusing a [dependency injection](/training/dependency-injection) framework like [Hilt](/training/dependency-injection/hilt-android) to replace components\nin your app at test time. See the [Hilt testing guide.](/training/dependency-injection/hilt-testing)\n| **Note:** On Android, you can also use the [Robolectric](/training/testing/local-tests/robolectric) framework, which provides a special type of test double, called shadows.\n\nNext steps\n----------\n\nThe [Testing strategies](/training/testing/fundamentals/strategies) page shows how you can improve your productivity\nusing different types of tests."]]