Automated tests are a powerful safety net. They are fast, repeatable, and protect against regressions. But they are not a substitute for actually running the code locally yourself.
Before I approve a pull request, I always check out the branch locally and test the code manually. It’s often the first thing I do as part of a code review. This is not because I distrust the person who wrote it or the test suite that passed it. It’s because nothing replaces the context and confidence you get from seeing a change work in front of you.
Understand the change at a deeper level.
Reading a PR in the browser makes it easy to skim. Pulling the branch down and running it makes me slow down and actually see what the change is doing. I can see how it behaves in practice, how it affects the rest of the system, and whether it really achieves its intended outcome.
That hands-on run often surfaces little details that are easy to miss in a static review. It helps me confirm not just that the code works, but it works in a way that makes sense for the product and the people using it. It also gives me deeper context for the code’s intended outcomes when I dive into the Github diff.
Confirm it meets requirements and designs.
A passing test suite only verifies what the author has written into the tests. It can’t tell you if the change actually meets the requirements, matches the designs, or aligns with the intended user experience.
Running the branch locally lets me compare the change directly against the specs and designs, checking if the details match the intent. I started doing this early in my career, when I was new to code reviewing. Most of the feedback I could think give was checking a change against the requirements. At the time, I did not have the experience to know what to correct just from reading the code, but when I’d test PR branches locally, it gave me an area where I could still make impactful suggestions. It has stayed part of my process because it consistently catches inconsistencies with requirements, even as my reviews now include far more code-focused feedback.
Spot edge cases and gaps in automated testing.
Tests are written by people, and people miss things. When I test PR branches locally, I often think of edge cases the author might not have considered. This can reveal situations they might have missed or should add tests for.
Additionally, while automated tests are valuable, they can still rely on mocks or only cover known conditions. I can certainly think of times where the test suite passed, but I found something that didn’t work because it was mocked in the tests. Local testing helps me catch issues before they reach production.
Conclusion: Tests are good, but manual testing is still important.
Tests are essential, but they can be limited, especially when they involve mocks or do not cover every possible interaction. Checking out a branch and running it locally is the fastest way to validate that a change truly works, makes sense, and fulfills the intended outcome. It can be extra important when a project has limited budget or scope for QA testing.
It’s a simple habit that consistently produces fewer bugs, better quality, and greater confidence in what we ship.