Lesson 13 · Senior testing practice

Testing strategy and the test pyramid in this repo

How to think about unit, repository, transport, and heavier tests as a portfolio — not a random pile of checks.

Your win: explain how this repo uses unit tests as the fast center of confidence, where they stop, and why the “pyramid” matters more as a reasoning tool than as a slogan.

In plain English Plain English: a strong testing strategy is deciding which layer should catch which kind of bug at the cheapest reliable point.

Why this page matters more than it looks

“Test pyramid” is one of those phrases people say so often that it can start sounding like decoration. The strongest earlier lessons in this course worked because they did not stop at vocabulary. They always answered a more practical question: what does this change how I test tomorrow?

That is the spirit of this lesson too. The senior step is not memorizing a diagram. It is learning how to choose the right test layer on purpose, defend that choice in code review, and avoid paying for realism when a smaller test could have caught the same bug more cheaply.

The question behind the pyramid

So here is the real question hiding behind the phrase: where should this bug be caught first? Once you ask that, the pyramid becomes useful again.

Some failures are basically logic mistakes and should be caught low, in fast isolated tests. Some failures are really about a boundary — transport mapping, repository scan behavior, or infrastructure semantics — and need a layer that can actually prove those facts honestly. The strategy is not “always unit tests” and it is not “always realism.” The strategy is the cheapest reliable proof for the thing you care about.

The strategy rule Catch logic mistakes low, boundary mistakes at the boundary, and only pay for heavier infrastructure when the cheaper layer cannot prove the thing you care about.

What the repo is actually doing

This repo already behaves like a team with a testing strategy, even if no one says “pyramid” out loud every day.

Usecase tests mock repositories and the DB layer because they are proving orchestration.
Repository tests use testutil.MockDB or driver-level fakes because they need stronger proof about query/scan behavior without paying for a real DB.
gRPC tests mock the usecase layer because the transport boundary is the thing being tested.
BDD/E2E exists elsewhere and is outside this course because it answers a different class of question at a much higher cost.

Once you see that pattern, a lot of review decisions get easier. You stop asking only “does this test pass?” and start asking “is this the right layer for the behavior it claims to prove?”

Backend use case When reviewing a new test, this lesson helps you ask whether the chosen layer is the cheapest layer that can still prove the behavior honestly.

Common mistake Treating “more realistic” as automatically “better,” even when a smaller isolated test would catch the same bug faster and more deterministically.

Map strategy to the repo

Use the repo testing map to classify which layers prove which kinds of behavior and where the scope boundary lives.

→ Repo testing map
→ .claude/rules/go-test-style.md

Check yourself (from memory)

Q1. The most useful senior reading of the test pyramid is…

Strategy is about bug-catching economics, not slogan repetition.

What is the senior question behind the test pyramid?

recall, then click to reveal

Which layer should catch this bug first, and what is the cheapest reliable test that can prove the behavior without paying unnecessary infrastructure cost?

Want me to turn this into a quick “which layer should test this?” decision tree? Ask me.

Sources. Repo testing map; house style rules.