Mock vs Fake test doubles: when to use a Fake Repository?
Tests if you know a Fake is a working lightweight implementation while a Mock verifies interactions. Good answers define Fake as in-memory with real logic, Mock as expectation-based, and choose a Repository Fake when many tests need reusable state.
What's really being asked
This question tests your grasp of the xUnit Test Patterns taxonomy and your ability to choose the right test double for Android architecture. A senior engineer should not just name definitions but explain the behavioral consequences: a Fake actually works like the real thing but with simplified resources, while a Mock fails the test if expected method calls do not happen. The interviewer wants to see that you think about maintainability across a large suite rather than just stubbing one unit test.
The full answer
First, define the conceptual boundary: a Fake is a lightweight, functional implementation such as an in-memory database or a Repository backed by a HashMap, while a Mock is a dynamically generated object used to verify that the system under test called specific methods with specific arguments. Second, explain the trade-off: Fakes are reusable and stable across many tests because they encapsulate real behavior, whereas Mocks couple tests to implementation details and require repetitive setup. Third, give the Android scenario: when testing a ViewModel that depends on a Repository, a Fake Repository lets you seed data, observe flows, and test integration without Robolectric or a real database, while a Mock would force you to stub every interaction and make tests brittle when the Repository adds new methods. Fourth, mention that Fakes are preferred for higher-level tests like ViewModel tests, whereas Mocks are acceptable for narrow unit tests of a class that purely delegates to a collaborator.
The mistakes people make
A red flag is saying that a Fake is just another name for a Mock or that both are created with Mockito. Another red flag is claiming that Fakes are always better; the candidate should acknowledge that Mocks are fine for verifying that a Logger or Analytics adapter was called exactly once. A third red flag is describing a Fake as a real implementation with a real database or network stack; by definition a Fake avoids I-O and heavy dependencies.
What usually comes next
The interviewer may ask how you keep a Fake in sync with the real Repository contract, so be ready to discuss maintaining a shared interface and writing contract tests. They may also ask about the other test doubles in the taxonomy, such as Stubs and Spies, or how Fakes behave in multi-module Gradle projects where the test source set needs to expose the Fake to downstream modules.
A concrete example
Imagine a NewsRepository interface with suspend functions getArticles and bookmarkArticle. A FakeNewsRepository stores articles in a MutableStateFlow and a mutable list of bookmarks. In a ViewModel test, you instantiate the Fake, seed it with three articles, call loadArticles, and assert that the UI state emits Success with those three items. If you had used a Mock, every test would need to stub getArticles to return a flow, and a change to the Repository signature would break every stubbing line instead of just the Fake implementation.
Interview question
When should you choose a Fake Repository over a Mock for testing an Android ViewModel?
- a.When you want a reusable, lightweight implementation that seeds state for many tests without stubbing every flowCorrect
- b.When you want to eliminate the Repository interface and inject test data directly into the ViewModel
- c.When you need to verify that the ViewModel calls specific Repository methods with exact arguments in order
- d.When you require an in-memory Room database to validate complex SQL queries against the real schema
Why? this is the answer
A Fake provides a working in-memory implementation that lets tests share seeded state and observe real flows, whereas option C describes the primary use case for a Mock, not a Fake.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
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