Mock vs Fake test doubles: when to use a Fake Repository?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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.

ONE 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.