Test Coverage
Fast recall
Quick revision
Core answer
Whether you understand Test Coverage beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
The commands:
go test -cover
# coverage: 50.0% of statements
go test -coverprofile=cover.out
go tool cover -html=cover.out -o coverage.html
# a browser view: green lines covered, red not
go tool cover -func=cover.out
# per-function breakdownExecuted on our test module: 50.0% of statements — the main() function's body (untested) accounts for the gap.
What coverage MEASURES: statement coverage — which lines of code the tests executed. It's the floor, not the ceiling: a line can be covered while its behavior is untested (called with wrong inputs and never checked). And branches matter more than lines: an if/else where only the true path runs is 'half tested' but count as one statement.
The honest interpretation: low coverage = you KNOW something is untested. High coverage = the tests EXECUTE most code (says nothing about assertion quality). Coverage is the map of what tests TOUCH, not proof they test.
The profile file: a line-per-statement format (file:line statements count). -html renders it onto your source — the fastest way to see the gaps.
The CI discipline: coverage as a floor (e.g., fail under 80%) — not as a target (100% is often worse: tests written to game the number rather than test behavior).
Test Coverage
Direct Answer
go test -cover runs tests with coverage instrumentation — shows what % of statements the tests execute. go test -coverprofile=cover.out + go tool cover -html shows line-by-line which code is tested.
Deep Dive & Architecture
The instrumentation mechanics: -cover inserts a counter array before each basic block (the compiler's atomic block structure). Each executed block increments its counter. At test end, the counters map to source ranges — the coverprofile format.
The statement vs branch distinction, quantified: a function with three if-else chains can show 100% statement coverage while only testing one branch of each — the statement count includes both branches, but running either one 'covers' the code. Branch coverage (a mode Go doesn't directly report in the standard tooling) would distinguish. For the interview answer: name the gap — statement coverage underestimates untested paths.
The gaming anti-pattern: tests that CALL functions without asserting (t.Error never called) — the code runs, coverage counts it, nothing is tested. The metric sees execution, not verification. That's why coverage floors are a floor, not a goal — assertion quality is the real quality signal.
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Test Coverage in a real project?
- How would you compare Test Coverage with an alternative?
- What is a common mistake when using Test Coverage?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.