Comparison questionMedium~7 min

Interview question

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 a payment command was issued once can be meaningful; verifying every logger and repository call usually copies the implementation. A fake is useful when many tests need richer behavior than a list of stubbed returns, but it needs contract tests against the real implementation or it can drift. I would not mock IQueryable or DbSet and claim that EF Core SQL behavior was tested.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I use a layered approach: doubles for fast domain tests, realistic infrastructure for integration risks, and sandbox or contract checks for external systems. If a third-party API is unavailable in CI, a local protocol stub can exercise our HTTP behavior while a smaller scheduled suite verifies the real sandbox. I document which layer can detect serialization, persistence, and provider drift. The suite makes the fidelity boundary explicit so failures and gaps are understood rather than hidden behind the word mock.

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.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The mock setup repeats the implementation's branches.
Tests cannot survive an internal refactor.
No test ever reaches the real serialization or persistence boundary.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why not mock EF Core queries?
When is interaction verification useful?
How would you keep a fake honest?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Opening drill

Comparison questionMedium~7 min

Interview question

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

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 a payment command was issued once can be meaningful; verifying every logger and repository call usually copies the implementation. A fake is useful when many tests need richer behavior than a list of stubbed returns, but it needs contract tests against the real implementation or it can drift. I would not mock IQueryable or DbSet and claim that EF Core SQL behavior was tested.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I use a layered approach: doubles for fast domain tests, realistic infrastructure for integration risks, and sandbox or contract checks for external systems. If a third-party API is unavailable in CI, a local protocol stub can exercise our HTTP behavior while a smaller scheduled suite verifies the real sandbox. I document which layer can detect serialization, persistence, and provider drift. The suite makes the fidelity boundary explicit so failures and gaps are understood rather than hidden behind the word mock.

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.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The mock setup repeats the implementation's branches.
Tests cannot survive an internal refactor.
No test ever reaches the real serialization or persistence boundary.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why not mock EF Core queries?
When is interaction verification useful?
How would you keep a fake honest?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

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 practice

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 practice