What is the difference between a mock, stub, and fake, and when would you avoid all three?

Choose between mocks, stubs, fakes, and real dependencies

Compares test doubles by purpose and explains when a real dependency provides a more trustworthy test.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A stub supplies controlled answers, a mock verifies an expected interaction, and a fake is a lightweight working implementation such as an in-memory repository with real state behavior. I use them to isolate a unit from slow or nondeterministic boundaries. I prefer a real dependency when its semantics are the thing I need confidence in, especially database translation, transactions, serialization, or framework configuration.

Full answer below

Practice focus

Test doubles, interaction verification, stateful fakes, real infrastructure, contract drift, and coupling.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
The terminology matters less than using each tool for a clear reason. Poor double choices can make a fast suite confidently test behavior that production never has.
A stub supplies controlled answers, a mock verifies an expected interaction, and a fake is a lightweight working implementation such as an in-memory repository with real state behavior. I use them to isolate a unit from slow or nondeterministic boundaries. I prefer a real dependency when its semantics are the thing I need confidence in, especially database translation, transactions, serialization, or framework configuration.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I mock narrow owned interfaces, not concrete framework internals. Verifying that a payment command was issued once can be meaningful; verifying every logger and repository call usually copies the implementation. A fake is useful when tests need richer stateful behavior than stubbed returns, but it needs contract checks against the real implementation or it can drift. I would not mock an ORM query provider and claim that database translation, constraints, or transaction behavior had been tested.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Mocking every dependency by default.
Using a list-backed fake as proof of SQL behavior.
Verifying incidental call order.
Letting fakes drift from production contracts.

What is the difference between a mock, stub, and fake, and when would you avoid all three?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Skill areas

Was this drill useful?

Found this answer useful?

Human editorial direction

What is the difference between a mock, stub, and fake, and when would you avoid all three?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Skill areas

Start a conversation

Was this drill useful?

Found this answer useful?

Human editorial direction