Make Copilot code review require tests and coverage

How can I make Copilot code review check tests and coverage before merge

Use GitHub branch protection or a ruleset to require test and coverage status checks before merge, then make your CI publish those checks on every pull request. Copilot code review gives feedback on the pull request, but merge blocking comes from required status checks, not from Copilot itself.

The practical setup is simple: run tests in CI, publish a pass or fail status, and require that status on the protected branch. If you already use GitHub Actions, the workflow should run on pull requests, and for merge queue setups it should also handle the merge group path GitHub documents for required checks.

Start with the branch you actually merge into, usually main or release. In the repository settings, add a branch protection rule or a ruleset for that branch, then enable required status checks before merging. GitHub documents that required checks must pass before a protected branch can be merged, and you can also require approving reviews in the same rule.

Choose checks that mean something. A check named tests is better than a generic build if the real gate is unit and integration tests. A separate coverage check works best when your CI can compute and publish code coverage as its own status. If you want one gate, make a single CI job fail when tests fail or coverage drops below your threshold.

The part people get wrong is assuming Copilot review can enforce this by itself. Copilot can comment on code quality and may point out issues, but GitHub’s merge gate is the status check. If the repository does not require the test and coverage check, a reviewer can still merge after reading Copilot’s comments.

A clean pattern is: pull request opens, CI runs tests, CI uploads coverage, CI reports a required status check, and GitHub blocks merge until that check is green. In parallel, Copilot review can stay enabled for human-style feedback on the diff. That gives you two layers, review comments and merge protection, instead of confusing one for the other.

If you use GitHub Actions, make the workflow trigger on pull_request so the check runs on the exact code that is being reviewed. GitHub also warns that required checks can become ambiguous if you reuse the same job name across multiple workflows, so keep job names unique when a branch rule depends on them.

Coverage deserves a careful rule. GitHub does not create a coverage gate for you, so your workflow needs to calculate coverage and then fail or pass in a way GitHub can see. The easiest version is a test job that uploads a coverage report and exits nonzero if coverage falls below the threshold. That keeps the merge decision inside one required check instead of asking reviewers to inspect a report by hand.

If you want the threshold to change over time, put it in the repository, not in a person’s memory. Store the limit in the CI config or test script, and require that the CI check itself is green before merge. That way the rule is visible in review, versioned with the code, and applied the same way to every pull request.

For teams using rulesets, GitHub’s docs describe the same basic idea: require status checks to pass before merging, and optionally require the branch to be up to date before merge. The strict setting matters when you want the tests to run against the latest base branch, not only the feature branch snapshot.

If you also use merge queue, update the workflow so it runs for GitHub’s merge queue path as well. GitHub documents that required checks may need the merge_group trigger in addition to pull request events. Without that, a branch can look ready in review and still fail later in the queue.

A useful workflow split is this: one job runs tests, one job collects coverage, and a final job aggregates both into a single required status. That makes the merge rule easier to read. If you require three separate checks, the PR has to stay green on all three, which is fine, but only if everyone understands what each one means.

The inconvenient part is that coverage by itself is not a quality guarantee. A test suite can hit the line target and still miss the risky behavior in the change. Treat coverage as a gate, not as proof. If the change touches parsing, permissions, billing, or state transitions, pair the coverage check with tests that exercise those paths directly.

If you want the team to trust the rule, write it down in the repository. Say which checks are required, which branch they protect, and whether the branch must be up to date before merging. GitHub’s protected branch settings and rulesets are the source of truth for that policy, so reviewers should not have to guess from tribal knowledge.

You can also combine Copilot review with code owners or required human reviews. That does not replace tests and coverage, it adds a second filter. The merge decision then becomes: human review, Copilot feedback, and required CI checks all need to agree before the branch moves.

If you want a fast implementation path, do this in order: add a CI workflow that runs tests on pull requests, make it publish a coverage result, create a branch protection rule on the target branch, require the CI status checks, then confirm the pull request cannot merge when one of those checks fails. That is the real control point.

DevConnect follows the same practical model for testing apps: use explicit gates, not assumptions. If you are building a workflow around real release readiness, keep the policy in the repo and the checks in CI, so the merge decision is automatic and visible. The platform itself is at https://devconnectplatform.com, but the merge gate for Copilot review still lives in GitHub.

A final check: open a pull request that intentionally breaks one test and lowers coverage. If the branch protection is wired correctly, GitHub should block merge and show the failed status check. If it still merges, the missing piece is not Copilot, it is the required status check configuration.