Why mock a Repository dependency in a ViewModel unit test?
This tests your grasp of test isolation. A great answer says mocking eliminates real database or network dependencies so you can verify ViewModel state changes in isolation. A red flag is insisting on using the real Repository inside the unit test.
What's really being asked
The interviewer wants to know if you understand the boundary between a unit test and an integration test. Specifically they are checking whether you recognize that a ViewModel unit test should validate mapping and state logic without being slowed down or made flaky by real I/O. They also care if you know how to use a mocking library to substitute a concrete dependency with a controlled test double.
The full answer
A good answer hits four things in order. First, state the goal of isolation: a unit test should exercise only the class under test, so dependencies like a Repository that touch disk or network must be replaced. Second, explain control: with Mockito you can stub methods to return specific data or throw exceptions on demand, which lets you test success paths, error paths, and edge cases deterministically. Third, mention speed and determinism: real Room or Retrofit calls make tests slow and flaky, while mocked responses run in milliseconds. Fourth, describe verification: Mockito verify lets you assert that the ViewModel called the right Repository method with the right arguments, ensuring the contract between layers is respected.
The mistakes people make
A common wrong answer is saying you mock only because the Repository is not implemented yet. That misses the point; you mock to isolate behavior even when the real implementation exists. Another red flag is claiming that mocking is too much boilerplate and that you should just use the real Repository with a test database. That conflates unit tests with integration tests. A third wrong pattern is mocking the ViewModel itself instead of its dependencies; the ViewModel is the system under test, so it should be instantiated with real constructor arguments while its collaborators are mocked.
What usually comes next
The interviewer may ask how you handle coroutines or LiveData in ViewModel tests. They might also ask about the difference between mocks and fakes, or when you would choose a fake Repository over a mocked one. Another common follow-up is how to test the ViewModel when it collects a Flow from the Repository, which opens discussion on TestDispatcher and turbine.
A concrete example
Suppose you have a NewsViewModel that calls newsRepository.getLatestNews(). In the unit test you create a mock of NewsRepository with Mockito. You stub the mock to return a list of two articles when getLatestNews is called. Then you instantiate the ViewModel with this mock and trigger the loading method. You assert that the ViewModel exposes a Success state containing those two articles. You also verify that the repository method was invoked exactly once. This proves the ViewModel correctly transforms repository output into UI state without ever hitting a real server or database.
Interview question
In a ViewModel unit test, what is the primary benefit of mocking its Repository instead of using the real implementation?
- a.So the ViewModel can be replaced with a mock to verify Repository interactions
- b.It lets you delay implementing the Repository until after the ViewModel is finished
- c.It keeps the test focused on ViewModel state logic without slow or flaky I/OCorrect
- d.It allows the test to verify that actual database queries return the correct data
Why? this is the answer
Mocking the Repository removes real disk and network dependencies, allowing the unit test to verify ViewModel state mapping quickly and deterministically. Option B is a common misconception—mocking is for isolation, not because the real implementation is missing.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #unit-testing
- #mockito
- #viewmodel
- #repository
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles