Lesson 16 · Senior testing practice

Choosing mocks vs DB fakes vs real collaborators

How to choose the right stand-in for the behavior you are trying to prove, without overpaying for realism or underpaying for signal.

Your win: explain when a simple mock is enough, when testutil.MockDB is the better fit, and when a heavier collaborator is justified outside the unit-test boundary.

In plain English Plain English: the right test double is the one that proves the behavior you care about without buying more infrastructure or brittleness than the case needs.

The choice behind every test

Earlier lessons taught you the mechanics of testify mocks and the house DB toolkit. The senior step is choosing between them deliberately rather than by habit.

That sounds small, but it is one of the clearest places where testing maturity shows up. Two people can both write a passing test, but the stronger engineer will usually choose the double that proves the behavior more honestly with less maintenance cost.

What each option is really buying you

A plain mock is great when the point of the test is orchestration: who got called, how many times, with what sort of behavior contract. But if the thing you actually care about is repository scan behavior, SQL-shape logic, or mapping detail, a plain mock may be too weak. That is where testutil.MockDB becomes useful: still cheap, still unit-test territory, but with stronger proof.

And sometimes even that is not enough. That is the moment where a heavier collaborator becomes justified — not because realism is automatically better, but because the lower layer cannot honestly prove the fact you care about.

The selection rule Use the cheapest stand-in that still proves the behavior honestly and specifically.

A practical reading of the options

Plain mock: fast, simple, best for orchestration and behavior expectations
testutil.MockDB: stronger signal for repository behavior, scan wiring, and SQL shape without a real DB
Real collaborator: only when lower layers cannot honestly prove the thing you care about

The important part is that each option answers a different question. Once you see that, “which one should I use?” becomes much easier to reason about.

Backend use case This is the lesson you want when reviewing a test and asking whether it is over-mocked, under-specified, or paying for realism in the wrong layer.

Common mistake Defaulting to the same kind of double everywhere instead of choosing based on what the unit is actually supposed to prove.

Compare the layers

Revisit the repo testing map’s “testing by layer” guidance and compare it to the repository and usecase lessons.

→ Repo testing map
→ docs/testing/lessons/0008-mocking-the-database.html

Check yourself (from memory)

Q1. How should you choose between a plain mock and testutil.MockDB?

Double choice should follow proof needs, not habit.

What is the senior rule for choosing a test double?

recall, then click to reveal

Use the cheapest stand-in that can still prove the behavior honestly and specifically at the layer you are testing.

Want a side-by-side comparison of “mock”, “MockDB”, and “real collaborator” decisions? Ask me.

Sources. Repo testing map; mocking/database lessons.