Coverage
Use coverage to find blind spots, not as a proxy for test quality; measure packages and integration paths deliberately.
Canonical guidance
- use coverage to discover untested behavior, not to declare success
- measure the packages and paths that matter
- prefer readable gaps over vanity percentages
Use when
- reviewing test blind spots
- comparing unit and integration coverage
- validating critical package boundaries
Avoid
- chasing 100 percent for its own sake
- assuming line coverage proves behavior coverage
- excluding hard cases just to keep numbers high
Preferred pattern
go test -cover ./...
go test -coverpkg=./... -coverprofile=cover.out ./...
Anti-pattern
- merging a coverage threshold rule that the team satisfies with shallow tests nobody trusts
Explanation: This anti-pattern is tempting because one number is easy to govern, but it is a weak proxy for real confidence.
Why
- coverage is a diagnostic input, not a substitute for good test design
Related pages
Sources
- go test flags - Go Team
- Code coverage for Go integration tests - Go Team