When writing test code, you eventually find yourself fixating on the coverage number.
I know the feeling of thinking, “If we’re doing it, we might as well reach 100%.”
To get straight to the point, code coverage in the 70–80% range is the most realistic target in practice, and 100% does not mean bug-free code. Let me explain why, based on my experience.
Here is the key summary first
For those in a hurry, here is the conclusion first.
- 100% coverage only means “every line was executed,” not “every case was verified.”
- The practical recommendation is generally around 70–80%.
- For critical logic such as payments and authentication, aiming for 90% or higher is worthwhile.
- Knowing “what you have not tested” matters more than the number.
Does 100% code coverage mean there are no bugs?
That is the most common misconception.
100% coverage only means that the tests “executed every line once.”
It does not mean they verified that each line behaves correctly.
Here is an example. In the function below, the test executes the code but does not properly check the result.
func divide(_ a: Double, _ b: Double) -> Double {
return a / b // bif 0? The test runs, but
}
// This test has coverage 100%, but
@Test func divide_only executes_the code() {
_ = divide(10, 2) // does not verify the return value(#expect)!
}This code reaches 100% coverage.
But because it does not check the result with #expect, it effectively guarantees nothing.
Coverage measures “how much was executed,” not “how well it was verified.”
That is exactly why you should not feel reassured by the number alone.
So what percentage is appropriate?
After working with several teams, I put the realistic standards I have experienced into a table. (Typical practical recommendations as of 2026)
| Code area | Recommended coverage | Reason |
|---|---|---|
| Core business logic | 90% or higher | Failures in payments or authentication can be critical |
| General service code | 70~80% | The range with the best return for the cost |
| UI and view layers | 50~60% | Change frequently and are expensive to keep testing |
| Generated and configuration files | Excluded from measurement | Testing has limited meaning |
Google has also publicly stated that it internally considers 60% “acceptable,” 75% “recommended,” and 90% “exemplary.”
There is no single correct answer, but you can consider around 80% a reasonable goal for most teams.
Why can insisting on 100% actually hurt?
The effort required to cover the final 20% is far greater than that required for the first 80%.
Testing every exception handler, hard-to-reach branch, and defensive check makes the time grow exponentially.
There is an even bigger problem.
You start getting “showcase tests” created just to raise the number.
Tests that raise coverage without actually verifying anything only get in the way when you change the code later.
Every refactoring then consumes time fixing meaningless tests.
Frequently Asked Questions (Q&A)
Q. Does that mean measuring coverage itself is pointless?
No. Coverage is extremely useful for finding areas that the tests never reach.
Rather than treating the number as a goal, use the coverage report to check the red areas (unexecuted code).
Q. Is it okay to enforce a coverage threshold in CI?
You can, but I recommend an approach such as “new code must be at least 80%.”
Applying a high threshold uniformly to the entire codebase exhausts the whole team because of legacy code.
Q. There seem to be several types of coverage?
It is a good idea to look at branch coverage alongside line coverage.
Whether conditions such as if/else have been properly tested is closer to actual quality.
Do not let the number chase you; first ask, “Is this test really protecting us from something?”
A solid test suite at 80% coverage is far more reassuring than a hollow suite at 100%. I hope you write great test code today too!