Get Your Coding Agent to Run Tests Before a PR

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

Make the agent run the repo’s test command before it is allowed to open the pull request, then enforce the same command in CI and require that check on the branch. The agent should fail fast on test errors and stop before it creates the PR. GitHub status checks and protected branches are the last gate.

The part people get wrong is trusting the agent’s intent instead of the repository rules. A prompt like “run tests first” is useful, but it is not enforcement. The real control is in the workflow: the agent runs a test command locally, the repository runs the same command on push or pull request, and branch protection blocks merge until that check passes. GitHub documents that required status checks must pass before merging, and protected branches can require those checks for all pull requests.

Start by naming one command that represents “safe enough to open a PR” in your repo. For many codebases that is npm test, pytest, go test./..., or a narrower target like npm run test:changed. Put that command in the agent instructions, in the local script it calls, and in CI. If you use more than one command, define the exact order so the agent does not skip the slower check after the quick one passes.

A practical setup looks like this: the agent edits code, runs the test script, fixes failures, and only then opens a pull request. In GitHub, the repository also runs the same script as a status check on the branch. If the check is required, the PR can exist, but it cannot merge until the check succeeds. That is the useful division of labor, because the agent catches obvious mistakes early and CI catches anything the agent missed.

If your coding agent supports a task list or policy file, put the test rule there in plain language. Use wording like: “Before opening a PR, run npm test. If it fails, fix the failure and rerun the test command. Do not open a PR until tests pass.” Keep the instruction specific to the repository, because “run tests” is too vague for multi-language projects where build, lint, unit tests, and integration tests are separate steps.

If the agent is driven by a shell script or automation job, make the script exit nonzero when tests fail. That part matters more than the prompt. An agent can ignore a suggestion, but it cannot ignore a failed process if the script stops the pipeline. The workflow should look like edit, test, fix, test again, then create the PR. The test command should be the same one humans use, so the agent and the team share one definition of done.

The inconvenient part is that “tests” should not mean only one fast command if your repo has more than one meaningful check. A unit test suite can pass while lint, type checking, or a targeted integration test still fails. If those checks matter before merge, put them in the same required CI path. GitHub status checks can cover build logs, test results, and other validations, and branch protection can require them before the PR merges.

For a GitHub-based repo, the cleanest enforcement is branch protection on the target branch plus a workflow that runs on pull requests. GitHub says required status checks must have a successful result before collaborators can merge changes into a protected branch. That means the agent can open a PR, but the repository will refuse to merge an untested change. If you want the PR itself to be impossible until tests pass, have your automation create the PR only after the local test step succeeds.

A useful pattern is to keep the agent’s PR-opening step in a wrapper script. The wrapper can do three things in order: run tests, capture the exit code, and call the PR creation step only on success. That wrapper is easier to audit than hidden agent behavior. If tests fail, the wrapper should leave the branch on disk so you can inspect the failure, rerun the command, and avoid creating noise in the review queue.

People also get tripped up by stale code. GitHub notes that required status checks may need to succeed against the latest commit SHA, and an out-of-date branch can require an update before merge. If your agent tested an older commit and then rewrote files again, the earlier green check no longer proves anything about the current branch. The fix is simple: test the final commit, not an earlier draft.

If your agent can call tools, give it a small decision tree. First, read the package or project scripts. Second, run the test command that matches the touched files. Third, if the command fails, repair the code and rerun. Fourth, if the command passes, open the PR with the test results in the description. OpenAI’s documentation for agent workflows emphasizes tool use, and GitHub’s docs make the enforcement side clear with checks and protected branches.

A concrete example in a JavaScript repo is: npm test for unit tests, npm run lint for style, and npm run typecheck for types. The agent should run the project-defined script, not invent its own shortcut. If the repo has a slower integration suite, keep that in CI and make it a required check if it is part of your release gate. The point is not to make the agent do everything, the point is to make it impossible to skip the checks that matter.

If you want a one-line rule to hand to the agent, use this: “Do not open a pull request until the repository’s test command passes on the final code, and do not treat the PR as ready until the required status checks are green.” That is short enough for a system prompt, but it still depends on repository enforcement to hold the line.

When it goes wrong, the usual failure is that the agent opens the PR after a partial check, or after tests passed on an earlier commit. The fix is not more persuasion. The fix is to make the test command part of the automation path and to require the check on the branch. Once that is in place, the agent can still help you write code quickly, but it cannot smuggle an untested change into review.

If you want, I can turn this into a repo-ready template for GitHub Actions, a shell wrapper, or an agent prompt you can paste into your coding tool.