A Go handler's tests all pass with a hand-written fake, yet production fails on lookup errors. Why?

## The failure Every test is green. Then a lookup fails in production and the endpoint returns a 500 with a useless body, or worse, a 200 with an empty user. The tests could not have caught it, because the stand-in they used never failed. ```go type fakeStore struct{} func (fakeStore) UserByID(ctx context.Context, id int64) (User, error) { return User{}, nil // every id "succeeds" } ``` This is the most common defect in hand-written test doubles, and it is a *silent* one: nothing is wrong with the code, the interface or the wiring. The double simply encodes an assumption — "the collaborator works" — and every test inherits it. ## Why zero values are so dangerous here Go's zero values make a method trivial to stub, which is exactly the trap. `User{}` is a perfectly usable value and `nil` is a perfectly usable error, so the code under test proceeds happily. There is no exception to notice, no null reference to blow up. If the service is supposed to distinguish "no such user" from "the database is down", neither path is ever taken, and the mapping from a store error to a status code — usually the whole point of the handler — is untested. The second-order effect is worse: a zero-value fake also lies about *arguments*. If the code passes the wrong id, or forgets to pass the request's context, the fake answers just the same. ## Fix 1 — the case decides the behaviour Give the fake fields, or function fields when a case needs to vary by argument or count calls: ```go type fakeStore struct { t *testing.T userByID func(ctx context.Context, id int64) (User, error) } func (f fakeStore) UserByID(ctx context.Context, id int64) (User, error) { f.t.Helper() if f.userByID == nil { f.t.Fatalf("unexpected call to UserByID(%d)", id) } return f.userByID(ctx, id) } ``` Two things happen here. The behaviour moves into the test case, where a reader can see it beside the assertion. And an unconfigured call becomes a failure instead of a zero value — the fake now says "you called something this case did not expect" rather than quietly succeeding. (If the collaborator may be called from another goroutine, use `t.Errorf` and return an error instead: `t.Fatalf` must be called from the goroutine running the test.) ## Fix 2 — write the failing cases A table with a `storeErr` column, one row per outcome, is the usual shape: a success, the not-found sentinel the real store returns, and a generic failure. Assert on what the code *does* with each — the status code, the wrapped error, the log — not merely that an error came back. Use `errors.Is` so that wrapping does not break the assertion, and check that the handler does not leak the raw store error text to the client. ## Fix 3 — verify the branch actually ran Coverage is the cheap confirmation: `go test -cover`, or `-coverprofile` plus `go tool cover -html` to look at the handler and see whether the error branch is coloured as executed. This is one of the few places where a coverage number is genuinely diagnostic rather than decorative, because the question is binary — did any test enter this branch at all? ## Fix 4 — make the fake resemble the real thing where it matters The real store returns `sql.ErrNoRows` for a missing row; if your code special-cases it, at least one fake must return that exact sentinel, or the special case is never exercised. Similarly, if the real implementation honours context cancellation, one case should return `context.Canceled` and assert the code does not treat it as a client error. The point is not to reimplement the database in the fake; it is to reproduce the *distinctions the code under test makes*. ## A review heuristic When reviewing a package's tests, read the fakes first and ask which of them can fail. If none can, the suite is testing one path in a system whose difficulty lives in the others. A fake that cannot fail is not a test double, it is an assumption with a method set. ## Related trap The same fake that always succeeds also hides a *dropped* error: if the code under test ignores the returned error entirely, no failing case exists to reveal it. That is why the failing cases matter more than the passing one — the happy path is usually the one that would have been caught anyway, by the first person to run the service.