Lesson 17 · Senior testing practice

Reviewing tests like a senior engineer

How to judge whether a test proves the right thing, fails for the right reason, and is worth the maintenance cost it adds.

Your win: review tests for signal, brittleness, blind spots, and truthfulness instead of treating “has tests” as the end of the conversation.

In plain English Plain English: a senior test review asks not only “does it pass?” but “what does it really prove, and how easily could it lie?”

Why test review is its own skill

Writing a test and reviewing a test are related, but they are not the same move. Writing is about expressing a behavior. Review is about judging whether that expression is honest, strong enough, and worth the maintenance cost it adds.

That is why senior review feels different. You are not only checking that a file exists or that the happy path is green. You are checking for false confidence, blind spots, brittle expectations, and cases where the test looks busy without really proving much.

The habit the earlier lessons already taught you

The strongest earlier lessons in this course were already honest about gaps. Lesson 9 pointed out that a passing flagship test was still incomplete because it missed important error paths. Lesson 12 kept warning that coverage can look good while behavior coverage stays weak. Senior review is really the continuation of that habit.

In other words: do not confuse green with complete, and do not confuse “has tests” with “is well tested.”

The review question What behavior does this test prove, what important behavior does it still not prove, and what fragile detail is it depending on unnecessarily?

What strong review comments usually target

missing error-path coverage
mock expectations that overfit implementation detail
assertions that are too weak for the intended behavior
shared setup that hides state leakage
test names that do not match the behavior actually covered

A good review comment is rarely “please add more tests” in the abstract. It is usually more specific: “this only proves the happy path,” or “this expectation is coupled to internal call order,” or “this assertion would still pass even if the important behavior broke.”

Backend use case When reviewing a PR with new tests, this lesson helps you move beyond “nice, there are tests” to “these tests prove the right thing and will stay useful over time.”

Common mistake Treating a green test file as automatically high-quality without checking whether the assertions are strong, the cases are complete, or the expectations are over-coupled.

Re-read the checklist as a reviewer

Look at the house coverage checklist and ask how it changes the comments you leave on a PR.

→ .claude/rules/go-test-style.md
→ docs/testing/lessons/0004-assertions-coverage.html

Check yourself (from memory)

Q1. What is the most senior question in a test review?

Senior review is about truthfulness and signal, not just existence.

What should a senior engineer ask during test review?

recall, then click to reveal

What behavior does this test prove, what important behavior is still unproven, and what fragile or unnecessary coupling might make the test lie or age badly?

Want a compact PR-review checklist for unit tests in this repo? Ask me.

Sources. House checklist; existing testing lessons.