Why does `go test` report 0% coverage for a package that another package's tests exercise?

## The default is narrower than people assume When you run `go test -cover ./...`, the toolchain builds one test binary per package and instruments **only that package's own source**. The dependencies it links are ordinary, uninstrumented builds. The percentage printed next to each package therefore answers a specific question: *how much of this package's code did this package's own tests run?* That default is right for unit tests and wrong for the two situations people hit most: 1. **An integration or end-to-end test package.** You have `./e2e` containing only `_test.go` files that start your server and hit it over HTTP. Its own package has almost no statements, and every package it exercises is uninstrumented, so nothing is credited anywhere. 2. **A package with no tests of its own.** `internal/store` is covered thoroughly by the handler tests in `internal/api`, but `go test ./...` shows it with no test files and no coverage. In both cases the code really did run. It just was not instrumented, and coverage can only report on instrumented code. ## What -coverpkg does `-coverpkg` takes a comma-separated list of package patterns and says: *instrument these packages, whichever test binary is being built*. ``` go test -coverpkg=./... -coverprofile=cover.out ./e2e ``` Now the `./e2e` test binary links instrumented copies of every package matching `./...`, and the resulting profile contains their blocks. `go tool cover -html=cover.out` will show your `internal/store` source annotated even though `internal/store` has no test file at all. You can also aim it narrowly: ``` go test -coverpkg=example.com/m/internal/store ./internal/api ``` which credits only the store package for whatever the API tests drive through it. ## What it costs, and what it changes about the number - **Build time and binary size.** Instrumented copies of the listed packages get compiled into *every* test binary in the run. On a large repo, `-coverpkg=./...` across `./...` is a noticeably heavier build than the same run without it — the cross-product is the reason. - **The denominator moves.** Without `-coverpkg`, each package's percentage is relative to itself. With it, the percentage `go test` prints for each package is relative to the whole instrumented set, and the output line says so — it reports coverage of statements in the pattern you named. A unit test that fully covers its own package can print a small number, which surprises people reading CI logs. - **Untouched packages count against you.** `./...` sweeps in `main` packages, generated code, and helper packages nothing exercises. They contribute statements to the denominator and zero to the numerator. - **Merging still matters.** Running `go test -coverpkg=./... -coverprofile=cover.out ./...` in one invocation gives a single profile covering everything; splitting the run across several invocations gives you several profiles that `go tool cover` cannot merge. ## Choosing the pattern deliberately The useful discipline is to make `-coverpkg` name what you actually want measured rather than reflexively writing `./...`. If the goal is 'how much of our business logic do our tests reach', a pattern like `./internal/...` excludes `cmd/` entry points and generated packages, and the number stops moving every time somebody adds a main package. If the goal is 'this one integration suite proves the store layer is exercised', name the store package alone and read the result as evidence about that suite rather than as a repository-wide score. ## The interview shape The question is usually posed as a puzzle: *our end-to-end tests clearly run this code, so why is it 0%?* The answer has two halves — instrumentation is per-package and defaults to the package under test, and `-coverpkg` is the flag that widens it — and a good candidate volunteers the third half unprompted: widening it changes the denominator and the build cost, so the number you get afterwards is not comparable with the number you had before.