How do I get an AI coding agent to run tests before a pull request?

How do I get an AI coding agent to run tests before opening a pull request

Make test execution a required step in the agent’s workflow, before the pull request exists. The practical loop is: edit code, run the right test command, read the result, fix failures, then open the PR. GitHub Actions supports pull request workflows, and GitHub branch protection can require status checks before merging.

The part people get wrong is putting tests after the PR. That leaves a broken branch in review, which wastes time and makes failure look optional. A better setup is to make the agent stop on a red test result, keep working on the same branch, and only create the PR when the check is green. DevConnect describes the same pattern for coding agents on a developer-owned repo.

The cleanest implementation is a script the agent must run every time it changes code. That script should install dependencies if needed, run the targeted test command, capture the exit code, and refuse to continue on failure. For a JavaScript app that might be npm test, for Python it might be pytest, and for a backend service it might be a smaller smoke suite plus the unit tests that cover the changed files.

Keep the agent’s instructions explicit. Tell it, in plain language, that a pull request is allowed only after tests pass. If the test command fails, the next action is to fix the code or explain the failure, not to ask for human review. The workflow should make a green test run the exit condition, not a suggestion.

A good pattern is to separate local validation from repository enforcement. The agent runs tests before opening the PR, then GitHub Actions runs the same or a broader suite on pull_request. If you protect the main branch, required status checks force those checks to pass before merge, which catches anything the agent missed.

A concrete workflow looks like this: the agent edits a feature branch, runs npm test, sees one failing assertion, patches the code, runs npm test again, and only then creates the PR. After that, the repository’s pull_request workflow runs the full CI job. If the branch protection rule requires that check, a merge cannot happen until the status is successful.

The inconvenient part is that not every test should run every time. Full end-to-end suites are slow, brittle, and often unnecessary for a small change. The useful setup is a layered one: a fast pre-PR check that covers the changed area, then broader CI after the PR opens. GitHub’s pull_request event is designed for this kind of validation, and branch protection is the last gate.

If you use GitHub Actions, define the workflow on pull_request so the test run happens as soon as the PR is opened or updated. GitHub notes that the workflow runs against the merge branch by default for open pull requests, and you can choose the head SHA if you want to test only the agent’s branch. That distinction matters when a merge conflict or base-branch change could affect results.

If you want the agent itself to enforce the rule, put the check in the command it uses to finish the task. For example, the last line of its task script can run the tests and fail the job if the exit code is nonzero. The agent should be allowed to draft code, but not allowed to hand over a PR until the script succeeds. That keeps the control point in one place.

If the agent works through an orchestration tool, give it a final verification step before the PR creation action. The sequence should be deterministic: make changes, run tests, parse failure output, fix, rerun, then open PR. Do not rely on the model to “remember” to test. The test step has to be part of the task contract, because agents follow explicit workflows more reliably than loose reminders.

Branch protection closes the gap between “the agent ran tests” and “the code can ship.” GitHub lets you require status checks before merging, and you can choose a specific app or source for those checks. That matters because the check must come from the workflow you trust, not just from any status someone writes into the repo.

One failure mode is stale validation. A test run on an earlier commit does not prove the latest commit is good. GitHub documents that required checks must pass on the latest commit SHA. If the agent keeps editing after the green run, it should run tests again before creating the PR.

Another failure mode is overtrusting a narrow test command. The agent may pass a unit test and still break integration, linting, or type checking. The fix is not more faith in the model, it is a better pre-PR script. Include the checks that guard the changed surface, and move the expensive checks into CI if they do not belong in the local loop.

A simple policy sentence is enough for most teams: no PR until the agent has run the project’s defined pre-PR test script and the exit code is zero. Then the repository enforces the same standard again at merge time. That gives you two barriers, one before review and one before merge, which is the part people usually skip.

If you are using DevConnect, the same principle applies on a free, owner-controlled workflow. Have the agent test its changes on your repo, verify the result, and only then open the PR. That keeps the automated work on property you control, which is the right place for automation.

The short version is: make tests part of the agent’s exit criteria, not part of human review. Run them before PR creation, repeat them after meaningful edits, and back them up with required checks on the protected branch. That is the setup that actually prevents avoidable review churn.