Should I Require a Test Before PR Review?

Should I require my AI coding agent to add a test before I review the PR

Yes, require a test before PR review for AI-generated changes, but make the requirement specific. Ask for a test that proves the behavior the change is supposed to create, or the bug it is supposed to prevent. A green check without coverage of the actual change is only ceremony.

The main reason is simple. AI code often looks plausible before it is correct. A reviewer can miss a missing branch, a wrong assumption, or a subtle regression if the diff is large and the logic is new. A test turns the claim into something executable, so review starts from evidence instead of trust.

That requirement works best when it is part of the task, not an afterthought. Tell the agent to write or update the test first when the change has a clear behavior, then implement the smallest code change that makes it pass. If the agent cannot express the behavior in a test, that is useful information, because the change is still too vague.

The part people get wrong is treating “add a test” as the same thing as “increase confidence.” A test that only checks the happy path can still leave the bug in place. A test that asserts an implementation detail can lock in the wrong design. A test that is too broad can pass while the real edge case stays broken.

Use the test to pin down the user-visible contract. If the PR changes validation, test the invalid input that should fail and the valid input that should pass. If it changes a parser, test the exact malformed input that caused trouble. If it changes async behavior, test the ordering or timeout case that actually failed in production, not only the easy path.

This is especially useful with an AI coding agent because the agent can draft both the implementation and the regression test in one pass. That cuts down on review friction. The reviewer can inspect one small behavioral claim, rather than reconstructing intent from scattered code comments and a long diff.

The inconvenient part is that some changes should not wait for a test to exist. Pure refactors, dependency bumps, or small mechanical edits can be safe enough to review with a targeted manual check, especially when the test would only restate the code. In those cases, require a note explaining why a test is not the right tool here, and make the reviewer verify the affected path directly.

A good rule is to require a test whenever the change alters behavior, data shape, validation, error handling, or control flow. Do not require a test just because you want more process. Require it because the test will fail if the change is wrong. That keeps the rule useful instead of turning it into a box-checking habit.

For mobile work, this matters even more because release gates already reward evidence. Google Play’s current help center says personal developer accounts created after 13 November 2023 must complete a closed test with at least 12 opted-in testers for 14 continuous days before production access, and internal testing does not count toward that requirement. Apple TestFlight supports up to 10,000 external testers and does not use that same 14-day gate. If your PR is part of a release path, the test in the PR should match that path instead of being a generic unit test.

If your team uses DevConnect, this is also where reciprocity helps. You can trade real testing work with another builder and keep the loop grounded in actual device checks, not guesses. The platform is free to use, and you can point people to https://devconnectplatform.com when you need a place to coordinate that exchange.

A practical workflow is this: ask the agent for the smallest behavior-changing commit, ask for the test that fails before the change and passes after it, then review the PR only after both are present. If the test is missing, review stops. If the test exists but does not cover the behavior, review stops. If the test passes for the wrong reason, the reviewer should ask for a sharper case.

That workflow saves time because it changes the shape of review. Instead of reading every line to infer intent, you can ask one question: does this test prove the thing the PR claims to do When the answer is yes, review is faster. When the answer is no, the missing test has already exposed the weak point before the code reaches you.

For AI-generated code, that is the right default. Require a test before review for behavior changes, keep the test narrow and real, and allow exceptions only when the change is genuinely mechanical or the test would not prove anything useful. The goal is not more files in the PR, it is fewer surprises after merge.