A green test gate shows that your tests passed on one build in one environment. It does not show that production behaviour is unchanged. Tests commonly miss performance shifts, configuration and environment differences, rarely used code paths and anything with no test at all.
Why say this out loud
Teams enabling automation often treat "checks passed" as "safe". The checks are only as good as the tests behind them. Renovate's documentation recommends automerge for updates you would merge anyway, and says production dependencies suit it when the project has good test coverage. The condition is the important part.
Five things tests often miss
1. Performance and resource use. A new version may be correct and slower, or hungrier for memory. Unit tests rarely measure either.
2. Configuration defaults. A library can change a default timeout, a retry rule or a log level. Your test environment may override the setting that matters in production.
3. Paths with no coverage. If no test calls the code that uses the package, the test gate says nothing about it. Reachability information helps here, because it shows which changed functions you actually call.
4. Interactions with the platform. Container base images, operating system libraries and runtime versions differ between CI and production.
5. Data shaped surprises. Real data has odd values that fixtures do not. A parser update can reject an input your tests never include.
Cheap checks that cover the gaps
| Gap | Check |
|---|---|
| Performance | Compare a simple load or timing run before and after on the PR branch |
| Configuration | Read the release notes for changed defaults, and grep your config for the affected options |
| No coverage | Add one test for the changed behaviour before merging |
| Platform | Run the PR build in a staging environment that mirrors production |
| Data | Replay a sample of recent requests against the new build, if your tooling allows it |
None of these is a large project. Pick the one or two that match your highest risk services.
Use the rest of the pipeline
A merge is not the last control. Deploy gradually where you can and watch signals after release. Google's SRE Workbook describes canarying as a way to find defects with as little impact on the service as possible, and gives the idea of evaluating whether the changed version is good or bad. For a practical routine, see what to watch after merging a dependency fix and canary a dependency fix before full rollout.
Be honest in the PR
When you merge, say what the gate covered. "Unit and integration tests passed, no performance check" is more useful in a later incident review than "CI green". It also shows reviewers where the gaps are, which is how test coverage improves in practice.
Try it yourself
Open the demo and see which kinds of checks run on a change. Ask yourself which risks in this post no check on the screen would catch.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Does reachability analysis replace tests?
No. It tells you which vulnerable functions your code can reach. It does not tell you whether the new version behaves the same.
What is the minimum extra check for a risky update?
Read the release notes for changed defaults and add one test for the behaviour you depend on.
Sources
Last reviewed: 19 October 2026.
