Keep Your Tests Close: Why Tests Belong in the Same Pull Request

Intended Audience: software developers, team leads

TL;DR Tests should be included in the same pull request as the code changes they test; this provides verification, eliminates risk, and guarantees no-fuss rollbacks.

Splitting code and tests is like rolling the dice on your product’s stability.

Automated tests are the safety net that catches bugs and prevents regressions—but only if they travel alongside the code they verify. Splitting new or updated tests into a separate pull request (PR) might seem like a way to keep PRs small or to “batch” testing work, but it introduces unnecessary risk. Below are three reasons to always bundle your tests with their corresponding code changes.

Reason #1: Tests Prove That The Code Works

A PR is an invitation to reviewers: “Here’s a change—please verify it.” Without automated tests, you’re effectively asking your reviewer to exercise every edge case manually—and if they’re going to do that, they might as well write the tests themselves.

However, as the PR author, you’re in the best position to codify your assumptions into deterministic, repeatable tests. Otherwise, every tweak or piece of feedback forces both you and your reviewer back into the same manual testing loop.

By instead bundling code and tests together, you ensure that every new or modified line ships with its own proof of correctness, and you never offload manual testing onto your team.

Think of it like publishing a scientific experiment: you share your theory alongside the reproducible “lab results” that anyone can rerun, guaranteeing the same outcome every time. In software, those “lab results” are your automated tests, and they should live in the same PR as the code they validate.

A PR without its tests simply isn’t ready for review.

Reason #2: Splitting Code and Tests is a Gamble

Splitting code and tests is like rolling the dice on your product’s stability:

1. Merge code without tests.

2. Continuous integration (CI) stays green.

3. Add tests later—and, surprisingly, they fail, exposing that either your feature never worked or it has regressed.

   
   

This “testing gap” lets bugs roam free in your main branch. When those issues surface, debugging them is more work and stress than it would have been if they'd been identified when still contained in your PR.

If you keep your code and tests in lockstep, your tests will catch issues the moment they are introduced. 

Reason #3: A Rollback Should Roll Back Everything

(Assuming you use a squash-merge or PR-based workflow—so that each PR becomes a single commit.)

Imagine you merge a PR that includes both code and tests, then discover a bug and trigger an automatic or manual revert of that PR. Because code and tests were bundled together, the revert cleanly removes both the feature and its tests in one atomic operation, and your main branch stays green. Happy days.

By contrast, if tests live in a separate PR or commit, a rollback of only the code can leave dangling tests behind. In many environments—especially those with strict branch-protection or CI-gate rules—this will:

• Break the build and block every subsequent merge until someone manually reverts or patches the orphaned tests.

• Erode the effectiveness of your rollback process, since “revert” no longer means “restore to a known good state.”

• Tie up the team in firefighting rather than letting them get right back to delivering value.

Even if your CI doesn’t automatically block merges, having a half-broken main branch is its own overhead: developers might pull a red build, spend time diagnosing why tests now fail, and wonder if they accidentally introduced the problem.

Bundling code and tests in the same PR ensures that any revert—whether manual or automated—always restores a fully green, coherent state. No orphaned tests. No blocked pipelines. No half-broken history. In other words, no chaos.

Conclusion

Tests aren’t an afterthought—they’re an integral part of your feature. By always including them in the same PR:

• You provide instant, reliable proof that your code works.

• You eliminate windows of risk created by split changes.

• You ensure clean rollbacks when needed.

Next time you open a PR, think of it as a complete package: code, tests, and all. Your future self—and everyone on your team—will thank you.

---

Do any of these arguments feel off the mark? Have you run into pitfalls I didn’t cover, or discovered additional benefits (or exceptions) in your own workflow? I'd absolutely love to hear your thoughts. Drop a comment below or reach out at erin@thepassionatecoder.com—let’s keep the conversation going and refine our collective best practices together!