A Go tool's -tags=integration suite was green for weeks without running. How do you prove that?

## Why this failure is invisible by construction Build constraints exclude files while the go command is assembling the package, before compilation. An excluded test file produces no test binary entry, so it cannot fail, cannot skip, and cannot print its own name. Every symptom of "the suite never ran" is therefore an *absence*, and absence is the one thing a pass/fail pipeline is bad at noticing. `go test` exits 0 for a package with no test files, which is correct behaviour — most packages legitimately have none — and it is why weeks can pass. ## Step 1: read the package line, not the exit code `go test` prints one line per package, and two of them look similar at a glance: ``` ok example.com/tool/migrate 0.412s ? example.com/tool/migrate [no test files] ``` The second says the go command found no test files in this build configuration. If the package is supposed to have an integration suite, that line is the whole diagnosis: nothing was compiled, so nothing ran. ## Step 2: ask the go command what it built `go list` reports the resolved file lists for the current build configuration: ``` $ go list -f '{{.TestGoFiles}} {{.IgnoredGoFiles}}' ./migrate/ [] [migrate_integration_test.go] ``` An empty `TestGoFiles` with the file sitting in `IgnoredGoFiles` proves a constraint excluded it rather than, say, someone deleting the file. Re-run the same command with `-tags=integration` and the file should move into `TestGoFiles`. If it does *not* move, the problem is in the file, not in the pipeline command — a typo in the tag name, or a misplaced constraint line. ## Step 3: the three causes, in likelihood order **The command never passed the tag.** Someone edited the job, split a step, or copied a template. This is the most common cause and the easiest to confirm: run the exact command the job runs, locally. **The tag name is misspelled in the file.** `//go:build integraton` is satisfied only by `-tags=integraton`. Tag names are arbitrary identifiers, so nothing validates them — no warning, no error, exit 0. Comparing the tag spelling in every constrained file against the spelling in the pipeline command is worth doing once and then automating. **The constraint is malformed or misplaced.** A `//go:build` line below the package clause, or one without a blank line after it, silently stops being a constraint. That direction of the bug makes the tests run *always*, which is loud; the direction that hides is a stray character in the expression that no configuration satisfies. `go vet`'s build-tag check catches misplaced and malformed lines, and `go test` runs that check by default. ## Step 4: prove the suite is alive, not just that it compiles `go test -tags=integration -list '.*' ./...` compiles the tagged configuration and prints the names of the test functions it found without running them — a fast, dependency-free way to assert that the suite exists in that configuration. A pipeline step that fails when this list is empty converts the silent failure into a loud one. A cheaper cousin is `go build -tags=integration ./...` or `go vet -tags=integration ./...` on every push: it type-checks the excluded files in seconds and catches the rot that silence hides. ## Step 5: fix the class, not the instance Once the cause is found, the durable fixes are structural rather than textual: - One documented tag name per repository, and one pipeline step per tag, so the two spellings live next to each other. - The tagged job asserts that it ran a known-non-zero number of tests. - Anything behind a tag has a scheduled build whose failure has an owner, because an excluded file is not type-checked by any other job. The underlying lesson generalises past this incident: with opt-in test selection, green is evidence about what ran, and says nothing about what did not. The pipeline has to be told what it is supposed to run before its silence can mean anything.