Test failure messages

Canonical guidance

• make the failure identify the case and input
• prefer stable, readable comparisons and diffs
• keep failure text consistent enough that large test suites stay easy to scan

Use when

• refining test diagnostics
• reviewing helper functions that report failures
• deciding how much detail a failure should print

Avoid

• opaque assertion failures with no input or case context
• unstable output that changes for unrelated reasons
• huge dumps when a focused diff would say more

Preferred pattern

t.Fatalf("Parse(%q) = %q, want %q", in, got, want)

Anti-pattern

• emitting only unexpected result and forcing the reader to rerun under a debugger

Explanation: This is tempting when the author already knows the test, but it is hostile to future readers and CI triage.

Why

• Google’s testing guidance is strongest where many Go docs are thinner: the exact shape of useful failure output