Picking Test Doubles — Prefer Fakes; Mocks for Interactions Only

Google has an unambiguous preference order for test doubles, stated three times on /training/testing/fundamentals/test-doubles. Most Android codebases over-mock and under-fake, which produces tests that pin implementation details (which methods were called) instead of behavior (what state the system landed in). This skill encodes the six doubles, the preference order verbatim, and a decision matrix for picking the right one. Framework-mechanics for the mocking libraries themselves live in sibling skills (../../../jvm-tests/mocking/mocking-with-mockito/SKILL.md, ../../../jvm-tests/mocking/mocking-with-mockk/SKILL.md).

When to use this skill

• The user asks "should I use a fake or a mock" / "Mockito or MockK" / "what's the difference between a stub and a spy".
• The user is replacing a dependency in a test and is unsure which double to reach for.
• The PR under review uses verify(repo).getUser(any()) everywhere and the agent suspects over-mocking.
• The user mentions Robolectric "shadows" and asks where they fit in the test-double taxonomy.
• The user says "every { repo.getUser() } returns User('Alice')" with no behavior under test and the agent should suggest a fake.

When NOT to use this skill

• The user already picked a fake / mock and wants framework mechanics (whenever / every / verify / argumentCaptor) — use ../../../jvm-tests/mocking/mocking-with-mockito/SKILL.md or ../../../jvm-tests/mocking/mocking-with-mockk/SKILL.md.
• The user is wiring Hilt to swap a binding — combine this skill with ../../strategies/applying-testing-strategies/SKILL.md (Hilt section).
• The user is choosing what to test, not how — use ../../concepts/choosing-what-to-test/SKILL.md.
• The user is debugging a Robolectric shadow that throws on a specific API — use ../../../jvm-tests/robolectric/using-robolectric-correctly/SKILL.md.