Reviewing test code in pull requests
Have a model review the test changes in each pull request — weak or missing assertions, tests that can't fail, deleted or disabled tests, and code changes that arrived without test changes.
How it works
Code review often focuses on production code, and test changes get a glance. A model reviewer is pointed specifically at the tests: does each new test assert on the behaviour the pull request changes, could it pass even if the feature were broken, are mocks hiding the very thing under test, were existing tests deleted, weakened or skipped, and did changed production code come with no test changes at all? It also checks the tests against the team's own conventions. Comments are posted on the pull request like any reviewer's, and the author responds. The narrow focus is what makes it useful; a general review assistant tends to skim tests the same way people do.
When to use it
Teams where test review is consistently thin; repositories with many contributors or AI-generated code; and pull requests that change behaviour in critical areas.
Limitations
Review comments are only as good as the model's understanding of what the change was supposed to do, which depends on the pull-request description. Too many minor comments train people to ignore the reviewer. It can't tell whether the right tests exist, only whether the tests present look sound.
Watch for
A test disabled by adding it to a skip list in the CI config, outside the test files the reviewer reads, so the review comes back clean. Point the reviewer at CI and test-runner settings too, and compare how many tests ran before and after the change.
What you still own
Deciding which comments matter, and judging whether the change is tested enough.
Cite this
Qlarify Labs. (2026). Reviewing test code in pull requests. Retrieved from https://labs.qlarify.fi/ai-in-testing/reviewing-test-code-in-prs