Read the Tests Before the Code
Review the tests first. The code second. Most reviewers open a pull request and scroll straight to the implementation — the new function, the changed branch, the clever refactor. But the diff already contains a plain-English spec of what the change is supposed to do: the tests. Read them first and you review with intent in hand instead of reverse-engineering it from the code.
Why tests come first
A test is the author telling you, in executable form, what behavior this change guarantees. It names the inputs, the expected outputs, and the edge cases the author thought mattered. That's the contract. Google's own code-review guide puts tests on the short list of things a reviewer must actively evaluate — not skim — because "tests do not test themselves, and we rarely write tests for our tests; a human must ensure that tests are valid."
Read the code first and you spend your attention decoding how it works. Read the tests first and you already know what it's supposed to do — so when you read the code, you're checking it against a spec instead of guessing at one. Tests also age better than comments: they're living documentation that fails when the behavior drifts, so what you read in the diff is current, not stale.
The mechanism
- Read the tests in the diff first. Note the behaviors they assert and the edge cases they cover. This is the author's stated intent.
- Read the code against them. Now every line answers a question you already framed: does this satisfy the contract the tests describe?
- Hunt the gap. The change touches a risky path — a new branch, an error case, a concurrency window, a boundary. Is there a test for it? A risky change with no test on its risky path is itself a finding. Write that comment.
| You see in the diff | What to check | Red flag |
|---|---|---|
| A new test | Will it fail when the code is broken? | Asserts nothing that can go wrong |
| A changed test | Why did the expectation change? | Loosened to make a bug pass |
| A new branch / error path | Is there a test that exercises it? | Untested risky path |
| No test change at all | Should there be one? | "Refactor" that alters behavior |
Green isn't reviewed
Passing tests mean the code satisfies the tests that exist. They say nothing about the tests that should exist. A change can be fully green and still ship an untested failure mode — the CI checkmark only covers the paths someone remembered to write. Reading tests first is how you catch the risky path the change quietly introduced, because you're comparing the set of tested behaviors against the set of changed behaviors and looking for the difference.
For the power user
- Ask the test the reviewer's questions. Will it actually fail when the code breaks? Will it start throwing false positives the next time the code underneath it moves? Does each assertion say something simple and useful? A test that can't fail is decoration.
- Watch the loosened assertion. The most dangerous diff is a test whose expected value changed with no explanation. That's often a bug being ratified. Make the author justify every relaxed expectation.
- Use it to steer your agent. When an AI agent opens a PR, point it at the tests first too: "review the tests in this diff, then the code, and flag any changed behavior with no test." The tests give the model the same grounding they give you — intent it can check the code against, instead of narrating the implementation back to you.
- Tests before code in TDD, tests before code in review. The symmetry isn't an accident: whoever reads the contract first does better work.
Resources
- What to look for in a code review — the Tests section (Google eng-practices)
- The Standard of Code Review (Google eng-practices)
- Unit Tests as Documentation: why tests are living docs (The Coder Cafe)
- Revealing Code Intent With Tests (Kostadin Golev)
<div class="cta"> <p><strong>Shipping AI agents that review or write code?</strong> Yeda AI designs, audits, and ships production LLM systems.</p> <p>More tips in the series · <a href="/contact">Talk to us</a></p> </div>