Green CI proves that the tests you have passed on the code as built. It does not prove the tests cover the changed behavior, that runtime configuration matches, or that nothing unrelated moved. Treat green as permission to start reviewing, not as the end of review.
Gap 1: coverage
If no test calls the library function you upgraded, the suite cannot fail because of it. Pick the feature that uses the library and find a test for it. If there is none, that is your answer: the upgrade is untested, whatever the badge says.
Fix: write one test that exercises the changed path, even a crude one, and keep it.
Gap 2: skipped checks
Branch protection accepts required checks that report successful, skipped or neutral. A workflow with path filters may skip itself on a manifest only change, and the PR still shows all clear. Look at the list of checks and confirm the important ones ran, not just passed.
Fix: do not use path filters on checks that guard dependency changes, or add a separate always-run job.
Gap 3: the check never started
Events created with the default workflow token do not trigger new workflow runs, with a few exceptions. A bot PR may show no checks at all, which is different from green. See required status checks for automated fix PRs.
Gap 4: environment differences
CI runs on a clean machine with a fresh install. Production has a different operating system version, native modules, environment variables and data. A library upgrade that behaves differently with a real database or a large payload will pass in CI.
Fix: deploy to staging and exercise the feature, especially for major bumps and native dependencies.
Gap 5: the lockfile
If CI installs with a command that updates the lockfile, it may resolve different versions than the PR shows. A frozen install, like npm ci, installs exactly what the lockfile says and exits with an error if the lockfile and manifest disagree. Use it in CI so what you reviewed is what you tested.
Gap 6: behavior that tests do not assert
Performance, memory use, log output, error messages and timing can change after an upgrade without breaking a single assertion. A fix for a parsing library might slow a hot path.
Fix: for services with load, compare a quick benchmark or watch dashboards after rollout. The rollback plan template includes a post-deploy watch step.
A review habit that works
Open the PR and ask three questions in order. Which test would fail if this change were wrong? Did that test run in this PR? Would I notice a problem in staging? If the answer to any is "I do not know," slow down.
Quick check
My PR has no checks at all. Is that fine?
No. Missing checks are not the same as passing checks. Find out why the workflow did not start before merging.
How much test coverage do I need before automating fixes?
There is no universal number. What matters is that the code paths that use your riskiest dependencies have tests. Measure by dependency, not by percentage alone.
Safeguard evidence on a fix PR can tell you whether the vulnerable code is reachable, which helps decide how hard to test.
Sources
Last reviewed: 19 October 2026.
