There is no coverage percentage that makes automatic fixes safe. What matters is whether your tests fail when an upgrade breaks something you rely on. Test that directly: apply a few real upgrades in a branch and see whether the suite catches the ones that should fail.
Why a percentage misleads
Line coverage counts lines executed, not behaviour checked. A test can run a function without asserting anything useful about its result. A project at 90 percent coverage can still miss a changed default in a library, while a smaller suite with sharp integration tests catches it.
Coverage also hides where the gaps are. The code that calls your dependencies, such as serialisation, authentication and database access, matters most for upgrade safety.
A practical readiness test
Run this on one repository before enabling anything:
- Pick three past dependency upgrades: one patch, one minor and, if you have it, one that broke production or a build.
- Reapply each in a throwaway branch.
- Run the full suite and note which ones fail.
- Ask whether the failing or passing result matches what really happened.
If the suite passes the upgrade that once broke production, your safety net has a hole around that dependency. Fix the hole first, or keep that repository on manual approval.
What to check besides unit tests
- Integration tests that exercise the libraries you upgrade most often.
- A build and startup check, so a missing or renamed export fails fast.
- Type checking and linting, which catch many API changes at no extra cost.
- A smoke test in a preview environment for services with external calls.
Make the important ones required status checks. See required status checks for automated fix PRs.
What to do with thin coverage
Low coverage does not rule you out. It changes the settings:
| Situation | Suggested setting |
|---|---|
| Strong integration tests, small releases | Manual approval, faster review |
| Moderate tests, some gaps | Manual approval, patch bumps first |
| Little or no tests | Manual approval, reviewer runs the app, add tests for hot spots |
In all three rows, merging without a person is off until you have evidence.
Improve the net where it matters
You do not need to raise coverage everywhere. List the five dependencies that touch the most critical paths, such as your web framework, database driver, authentication library, serialisation library and HTTP client. Add one integration test per dependency that would fail if its behaviour shifted. A week of that work buys more upgrade safety than months of chasing a percentage. Re-run the past upgrade test afterwards to confirm the new tests catch what they should.
Where Safeguard fits
Safeguard's autonomous remediation is off by default with every category on Manual, so thin coverage does not force a decision. Policies and gates can require checks before a change merges. A free scan shows the volume of fixes you would be reviewing.
Quick check
Is 80 percent coverage enough?
It depends on what the tests assert. Use the past upgrade test above instead of a target number.
Do type checks count as tests here?
They catch many API breaks, so they are a useful required check, but they do not replace tests of behaviour.
Last reviewed: 19 October 2026.
