A passing test suite is reassuring, but it does not show which parts of the code the tests never reach. Code coverage reports the percentage exercised by tests and highlights missed areas. Use it to find the next useful test, not as proof that the product works as intended. section 3.7
A practical coverage loop is:
- Run the tests with coverage enabled. In Go, `go test ./... -cover` gives a quick view across packages. section 3.7
- Inspect the missed code. Look especially for logic branches and error conditions that deserve tests; consider removing code that is no longer used. section 3.7
- Add tests that check the code’s interface and expected behavior, then measure again. High coverage is useful, but 100% is not required. section 3.7 section 3.8
Make coverage visible
A Makefile can have `make test` write `coverage.out`, `make coverage` check the total, and `make report` create `cover.html`. The illustrated check uses 80% as a gate. Open the HTML report to locate tested and untested lines, then choose a meaningful missing case rather than writing a test solely to raise the number. section 3.7
Listing 3.22 Makefile
test:
go test ./... -coverprofile=coverage.out #1
coverage:
go tool cover -func coverage.out | grep "total:" | \
awk '{print ((int($$3) > 80) != 1) }' #2
The Makefile listing shows how the test target creates a Go coverage profile and a separate target checks its total. section 3.7
Run the check in continuous integration so developers receive the same feedback on each push. The illustrated pipeline runs tests, checks coverage, generates an HTML report, and archives that report. Keep watching test duration as the suite grows: coverage is one signal alongside whether unit, acceptance, and integration tests give timely feedback before release. section 3.7 section 9.5
