Why does a Go test report the failure line inside a helper function, and what does t.Helper fix?

## What the failure line actually is When a test calls `t.Errorf("Enabled(%q) = false, want true", flag)`, the testing package prints something like: ``` engine_test.go:41: Enabled("checkout_v2") = false, want true ``` That `engine_test.go:41` is not the line of the test function and not the line of the thing under test. It is the source position of the **call to `t.Errorf` itself**, recovered from the call stack at the moment of the call. That is exactly what you want while the comparison is written inline in the test body. It stops being what you want the moment you factor the comparison into a helper. ## The failure mode A suite grows a helper — `assertEnabled(t, e, flag)`, `requireNoError(t, err)`, `checkRule(t, got, want)` — because the same three lines were repeated forty times. Every call site now funnels through one `t.Errorf`. The output becomes: ``` helpers_test.go:12: Enabled("checkout_v2") = false, want true helpers_test.go:12: Enabled("beta_ui") = false, want true ``` Every failure points at line 12 of the helper file. You can still read the message, and a well-written message carries the inputs — but you have lost the one thing a file:line is for: jumping straight to the assertion that broke. In an editor or CI annotation that renders the reported position, every failure lands on the same irrelevant line. ## What t.Helper does `t.Helper()` takes no arguments and returns nothing. It records the *calling function* as a test helper for this test. When the testing package next needs a file and line to attribute a log or failure to, it walks up the stack and skips frames belonging to functions that have been marked. The first unmarked frame is what gets printed — the line in the test function that called the helper. Three properties matter: - **It is per function, not per call chain.** If `assertEnabled` calls `checkBool`, and only `assertEnabled` is marked, the reported line is inside `checkBool`, because that frame was never marked. Every level of the chain needs its own `t.Helper()`. - **It is idempotent and cheap**, which is why the convention is to call it as the very first statement, unconditionally, rather than only on the failing branch. - **It affects attribution only.** It does not change which test is marked failed, does not convert a `t.Fatal` into a `t.Error`, and does not suppress anything. ## What it does not do It does not touch panic stack traces. If the helper dereferences a nil pointer, the runtime prints the whole stack including the helper, because that trace is produced by the runtime, not by the testing package's attribution logic. It does not change *which* test the failure belongs to. That is decided entirely by the `*testing.T` value the helper was given. A helper that takes a subtest's `t` fails that subtest; the same helper given the parent's `t` fails the parent. And it does not change what `t.Fatal` inside the helper means. `Fatal` calls `FailNow`, which ends the goroutine running the test with `runtime.Goexit` — so a `Fatal` inside a helper aborts the test that called it, and the lines after the helper call in that test never run. That is often desirable for a `requireNoError`-style guard, but it is worth being deliberate about: a reader skimming the test body sees a function call, not an obvious exit point. ## Signature conventions for helpers By convention a test helper takes `t *testing.T` as its **first** parameter, so it reads like the standard library's own helpers and so the marking call has something to be called on. Helpers that return a value instead of failing (a constructed fixture, a parsed input) are equally idiomatic; the ones that report failures are the ones that need marking. A helper that both fails and returns a value is fine — but if it uses `t.Fatal`, remember it will not return at all on the failure path, so any code you wrote assuming a fallback value is dead. ## Reviewing for it On a pull request, the tell is a helper whose body calls `t.Error`, `t.Errorf`, `t.Fatal` or `t.Fatalf` and whose first statement is not `t.Helper()`. It is a one-line fix and it is worth asking for every time, because the cost of not having it is paid by whoever triages a red run six months later, not by the author.