Running Tests
Fast recall
Quick revision
Core answer
Whether you understand Running Tests 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 command and its flags:
go test # all tests in the current package
go test -v # verbose — each test name + PASS/FAIL
go test ./... # all packages
go test -run TestX # only matching tests
go test -count=1 # no cache (re-run)
go test -race # with the race detector
go test -cover # coverage percentageThe file convention: a test file is func TestXxx(t *testing.T) — capitalized Test prefix, a *testing.T parameter.
The output, executed:
=== RUN TestDouble
--- PASS: TestDouble (0.00s)
=== RUN TestSkip
main_test.go:35: not ready
--- SKIP: TestSkip (0.00s)
PASS
coverage: 50.0% of statementsEach test is its own goroutine (parallel-safe via t.Parallel()). The test binary is the package's code plus the test files — it compiles once, runs in-process.
Running Tests
Direct Answer
go test — runs every _test.go file's Test* functions. go test -v for verbose (each test shown). go test ./... for the whole module.
Deep Dive & Architecture
The file discovery: go test compiles the package plus any _test.go files into a single test binary, which the go tool runs. Test functions are found by the exported Test prefix + the testing.T signature. Example functions (Example) and benchmarks (Benchmark) are the same mechanism with different entry types.
The -v flag: sets the test binary's -test.v flag — each test prints === RUN and its PASS/FAIL line. Without it, only package-level PASS/FAIL.
The caching: go test caches results by the package's content hash — unchanged code = 'ok (cached)'. -count=1 disables (the flag every debugging session adds). The cache is correctness-preserving (it hashes inputs) but defeats 'did it actually run this time.'
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 Running Tests in a real project?
- How would you compare Running Tests with an alternative?
- What is a common mistake when using Running Tests?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.