A comprehensive test suite confirms that the code does what you told it to do.
A human review confirms that what you told it to do is what you actually want.
The test that passes but the code is wrong
def eligible_for_discount?(purchase_amount)
purchase_amount > 100
end
Test:
assert eligible_for_discount?(101)
assert !eligible_for_discount?(100)
assert !eligible_for_discount?(99)
All pass. The code is wrong. The rule is “greater than or equal to 100” not
“greater than 100.”
The test writer and the code writer made the same mistake. The test
confirmed the mistake.
What a review finds
A human reading the code asks: “What if the amount is exactly 100?” and finds
the boundary is wrong.
The logic that is technically correct but practically wrong
def refund_request_days_remaining(purchase_date)
days_since = (Date.today - purchase_date).to_i
30 - days_since
end
The test passes. The code is correct. But if a customer bought on day 0, they
have 30 days. If they bought on day 1, they have 29 days. If they bought on day
30, they have 0 days.
The business rule is probably “within 30 days of purchase,” which means day 30
should have 1 day remaining, not 0.
A test can confirm the calculation. Only a human can catch the off-by-one
business logic.
The performance that is not tested
def find_active_users
User.all.select { |u| u.active? }
end
The test passes. The code is correct. With 100 users the query is fast. With
100,000 users it is a DOS attack waiting to happen.
A test cannot measure intent. A human can ask: “What happens when this table
grows?”
Why this matters
Tests confirm the implementation. Reviews confirm the intention.
A reviewed test suite is one where the code does what you meant and does it
efficiently.
An untested review is one where clever code breaks in production. A tested
review is one where clever code fails fast and obviously.
The review that asks “Is this right?” catches the bug. The test that asks
“Does this work?” catches the typo. Both are needed.