Example Functions
Fast recall
Quick revision
Core answer
Whether you understand Example Functions 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 shape, executed:
func ExampleDouble() {
fmt.Println(double(21))
// Output: 42
}go test runs it: double(21) prints 42; the Output: comment says 42 — PASS (verified in our test module).
The doc relationship: Example functions become documentation — pkg.go.dev shows them alongside the function they demonstrate (ExampleDouble documents Double by example). The reader sees the call AND the expected output — and it's TESTED: change double()'s behavior and the Example fails — the docs can't rot.
The naming convention: Example + the function name (ExampleDouble documents Double). Variants: ExampleDouble_negative — a named suffix; ExampleDoubleSuite if the function is in a different position.
The Output comment rules: the exact expected stdout (leading/trailing whitespace matches; blank lines separate multiple outputs). No Output comment = the Example runs but isn't verified (still useful as doc).
The discipline: Examples ARE the API's usage spec — write them for anything users will call, and they double as the tutorial. The standard library is full of them — the stdlib docs ARE Examples.
Example Functions
Direct Answer
func ExampleFoo() in _test.go — a function that prints output and has an Output: comment. go test runs it and FAILS if the printed output doesn't match the comment. Executable, testable documentation.
Deep Dive & Architecture
The mechanism: the test framework compiles Example functions, captures their stdout (redirecting os.Stdout for the duration), and compares — exact match against the Output: comment. The comparison is string-equality on the captured output, which makes Examples deterministic-only — no time, no random, no network output.
The doc-site integration: pkg.go.dev and godoc extract the Example's source (the body) and the Output comment, rendering them as the function's example section. The Example is tested code that becomes documentation without any additional step — the single-source-of-truth documentation pattern.
The relation to the other test types: Example functions are the ONLY test form that's both executable AND rendered — Test functions are internal assertions; Examples are the public-facing documentation that the test suite verifies. Together with table-driven tests, they're the Go community's answer to 'documentation that lies' — the doc can't drift because it fails the test when it does.
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 Example Functions in a real project?
- How would you compare Example Functions with an alternative?
- What is a common mistake when using Example Functions?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.