Run Tests Before PR Review or After?

Do I need to tell the AI coding agent to run tests before it opens a pull request, or can I review first

Tell the AI coding agent to run tests before it opens the pull request. Review the code yourself too, but review should sit on top of a test run, not replace it. GitHub’s pull request flow is built around review and automated checks together, and GitHub says pull requests can run tests, builds, and code scanning before merge.

The part people get wrong is thinking this is a choice between speed and quality. It is not. If the agent opens a pull request without running tests, you move the failure from the branch to the review thread, and every reviewer now spends time on code that may already be broken. GitHub’s docs treat checks as part of the pull request state, because reviewers need that signal before they decide whether the change is ready.

Review first is still useful, but use it for a different job. Self-review is where you catch bad logic, awkward structure, naming problems, and missing edge cases. Tests are where you learn whether the change actually holds together. GitHub explicitly describes pull requests as a place to discuss and review changes before merge, and it also describes checks as the place where automated validation happens. Those are separate gates.

The convenient version is simple: ask the agent to work in this order, make the branch, run the tests locally or in CI, fix failures, then open the pull request for your review. GitHub says you can build and test updates locally before pushing, or run CI on new commits in the repository. That workflow keeps the pull request focused on review, not on basic debugging.

If you review before tests, you should expect a second round of work. You may approve a design that later fails a unit test, or you may spend time commenting on code that disappears when the agent fixes the test failure. That wastes attention on both sides. GitHub’s status checks are designed to show whether a pull request is ready to merge, and required checks must pass before merge on protected branches.

A practical prompt for the agent is: implement the change, run the relevant tests, fix any failures, and only then open the pull request. If you want, add one more instruction, summarize what was tested and what is still untested in the pull request description. That gives reviewers a clean starting point and makes gaps visible instead of hidden. GitHub’s pull request model already organizes conversation, commits, checks, and files changed separately, so the description should support that structure.

There is one inconvenient truth here, and it matters. Tests are not a substitute for review, and review is not a substitute for tests. A change can pass every test and still be wrong in a way a person notices immediately. A change can look reasonable in a diff and still break the build. GitHub’s own guidance keeps both in the process: review the pull request, and use checks to validate it.

For AI coding agents, the safest rule is: do not open a pull request as the first step after generation. Make the agent prove the branch is at least minimally sound first. If the repository has a test suite, run the tests. If it has linting or code scanning, run those too. GitHub’s Copilot docs for stacked AI-generated code say to run tests, linters, and code scanning on each branch before you request reviews. That is the right order even when the branch is small.

If the code is large, the order matters even more. Large pull requests are harder to review and create bottlenecks. GitHub recommends splitting AI-generated work into smaller layers and checking each layer before asking for review. That is the same principle as test-before-review, just applied to branch size. Smaller reviewed changes are easier to trust, and smaller failed changes are easier to fix.

A good workflow for a real team is this: ask the agent to implement one focused change, run the tests, inspect the output, fix failures, then open the pull request in draft if human review is not yet needed. After your own review passes, mark it ready for review. GitHub supports draft pull requests for this exact staging step. That keeps the branch visible without pretending it is ready.

If your goal is to save reviewer time, tell the agent to include the test result in the pull request body. Mention the exact command it ran and whether it passed. Do not ask for a review until the branch is in a state you would merge if no one else existed. That standard is stricter than “looks fine in the diff,” and it is the standard that avoids the most expensive back-and-forth. GitHub’s docs put reviews and checks side by side for a reason.

If the agent cannot run tests in its environment, make that explicit in the prompt and require the pull request to say so. Then run the tests yourself before asking for review. The key is honesty in the handoff. Reviewers can work around a missing test run, but they should not have to discover it by accident after spending time reading code that was never validated. GitHub’s review flow gives them comments, approval, and requested changes, not a substitute for verification.

The short answer is yes, tell the agent to run tests before it opens the pull request. You can review first, but only as your own internal check. The review that matters to teammates comes after validation, because that is the stage where the pull request is actually ready to be judged.

If you are using DevConnect to find a human tester for the branch, keep the same order: validate the code first, then ask someone else to review what passed. DevConnect is free to use, and it is built around reciprocal testing on projects people control, not around skipping validation or paying for a shortcut. https://devconnectplatform.com

A concrete prompt you can give the agent

Implement the feature, run the relevant tests, run lint if the repo has it, fix failures, then open a pull request only after the branch is green. In the pull request description, list what you tested, what passed, and what you did not test.

What happens when you get this wrong

The agent opens a pull request before any tests run. A reviewer sees a broken import, a missing edge case, or a failing build, and now the review turns into debugging. The same branch often needs another round of edits, another review pass, and another wait for checks. That is the slow path, and it looks efficient only until the team has to use it twice.

What happens when you get it right

The agent opens a pull request after tests pass. You review the diff for logic and design, not for basic breakage. Reviewers can focus on whether the change should exist, not on whether the branch can even run. That makes the pull request useful, because the review thread is spent on decisions instead of cleanup.

Practical rule

Run tests before the pull request. Review before merge.

FAQ

Can I approve code before tests run? You can, but you should not treat that approval as final. GitHub’s workflow separates review from checks, and required checks can still block merge until they pass.

Should the agent run only unit tests, or also lint and code scanning? Run whatever the repository uses as its quality gate. GitHub’s docs explicitly include tests, builds, and code scanning as checks that belong with pull requests.

What if the repo has no test suite? Then the agent should still do the strongest validation the repo supports, such as linting, type checks, or a build. If none exist, your review becomes more important, but it still should happen after the code has been inspected locally or in CI.

Should the pull request be draft until I review it? Yes, if you want to stage the work without asking for review yet. GitHub supports draft pull requests for exactly that kind of checkpoint.