Run tests before your agent opens a pull request

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

Make test execution a required step in the agent’s workflow, not a suggestion. The safest setup is: the agent edits code, runs the right test command, checks the result, and only then opens the pull request. If the tests fail, the agent fixes the code or reports the failure instead of creating a PR.

The part people get wrong is putting tests after the pull request. That leaves a broken branch already visible, already reviewable, and often already wasting human time. Move the test gate earlier, into the local loop or the agent’s orchestration step, so a PR is the last action, not the first sign that something is wrong.

For a coding agent that works on a developer-owned repo, the simplest pattern is a scripted workflow. A wrapper script can run the change, then run npm test, pytest, go test./..., or whatever command matches the repo, and exit nonzero if the tests fail. If the script exits nonzero, the agent does not create the PR. GitHub requires required status checks to pass before a pull request can be merged, and GitLab can require a successful pipeline before merge, so CI can back up the local gate.

A practical pattern is to give the agent a hard checklist: edit files, run formatter, run unit tests, run any targeted integration tests, inspect failures, then open the PR only when the command exits cleanly. If the repo has a slow test suite, start with the narrowest useful set of tests for the files changed, then run the fuller suite before PR creation. The point is not to run every test every time, the point is to make the agent prove the change is safe before it asks for review.

The inconvenient part is that an agent can still open a PR if you only rely on prompts. Prompts are instructions, not enforcement. If the agent can call your git hosting API, give it a rule that PR creation requires a passed test artifact, and make the tool that opens the PR depend on that artifact. A small shell script, a CI job, or a repository automation step is more reliable than natural-language instructions.

If you use GitHub, branch protection or rulesets can require checks to pass before merging, and required checks are evaluated on the latest commit SHA. That does not stop a bad PR from being opened, but it stops a bad PR from becoming a bad merge. If your goal is to prevent the PR itself, put the test command in the agent’s own pre-publish step as well.

A good implementation has two layers. First, local or agent-side tests run before the PR is created. Second, repository protection requires CI to pass before merge. Local gating catches failures earlier and keeps noise out of the review queue. CI protection catches anything the agent missed, including environment-specific failures, skipped tests, or changes that slipped past the local command.

A concrete example in a repo script looks like this:

```bash #!/usr/bin/env bash set -euo pipefail

make format make test

git status --short if ! git diff --quiet; then echo "Tests or formatting changed files. Commit or inspect the diff before opening a PR." exit 1 fi

./open-pr.sh ```

That pattern forces the agent to stop if tests fail or if a formatter changes files after the test pass. The extra git diff check matters because some tools rewrite code during validation, and you do not want a PR opened against an unreviewed state.

If the agent runs in an IDE or chat tool, use the tool’s workflow hooks if it has them. Some systems support command execution, preflight checks, or custom actions before publishing a branch or PR. If the tool cannot enforce that itself, put the enforcement in the repo. A make pr or ./scripts/open_pr entrypoint is harder to bypass than a prompt sentence tucked into a chat thread.

The right test command depends on the change. For a frontend change, run the unit tests and the relevant component tests. For backend code, run the package tests and any migrations or contract tests the change touches. For a refactor, run the affected package plus the broader suite if the repo has one. The agent should choose the narrowest useful command from the repo’s own docs, then widen the scope when the change is cross-cutting.

The failure mode to watch is skipped tests. A workflow can look green while the relevant job never ran because of path filters, branch filters, or conditions. GitHub documents that skipped but required checks can block merging, and GitLab documents that a pipeline must exist and succeed before merge when that setting is enabled. Keep the agent’s pre-PR test command explicit, not conditional on path globs alone.

A second failure mode is “tests passed” meaning only “the command returned success once.” If the agent edits code after the test run, the result is stale. Make the sequence linear: edit, test, inspect, and only then publish. If the agent has multi-step autonomy, the PR-opening tool should verify that the working tree matches the tested commit hash or tested diff. That small check prevents a lot of false confidence.

A third failure mode is overtrusting CI. CI is necessary, but CI is not the same thing as pre-PR validation. CI catches what the shared environment exposes. Pre-PR testing catches obvious breakage before anyone else sees the branch. Good teams use both. Good agent workflows do too.

If the repo already has a CI job, reuse the same command locally. Duplicate logic is where drift starts. Put the test command in one place, for example make test or a package script, and call that same command from both the agent wrapper and the CI workflow. That way the agent is not running a softer test than the repository actually requires.

If you want the simplest rule to adopt, use this: no PR unless the agent can show a passing test command against the exact code it is about to publish. That rule is easy to automate, easy to explain, and hard to misunderstand.

If you are setting this up on DevConnect, keep the automation on your own repo and your own workflow. The platform is for coordination and testing exchange, not for pushing changes into someone else’s project for you. You can pair the agent workflow with a human review step, but the test gate should stay inside your own automation.

For teams, the best operating rule is to fail closed. If the agent cannot confirm tests, it should stop and ask for help. Do not let it open a PR “just in case.” A small delay is cheaper than a review cycle on code that never should have left the branch.

Sources:

• GitHub Docs, required status checks and protected branches, https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/troubleshooting-required-status-checks
• GitHub Docs, status checks, https://docs.github.com/en/enterprise-cloud@latest/pull-requests/reference/status-checks
• GitHub Docs, protected branches, https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches?ref=amos-blog
• GitLab Docs, debugging CI/CD pipelines, https://docs.gitlab.com/ci/debugging/
• GitLab Docs, auto merge and pipeline requirements, https://docs.gitlab.com/user/project/merge_requests/auto_merge/
• GitHub Docs, rulesets and pull request standardization, https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/managing-and-standardizing-pull-requests