Testing in Go: what t.Run, t.Parallel and a benchmark really do

What is really being asked

The ladder is almost always this one:

1. "What is a table-driven test?" — the warm-up; "a table of cases" is right, but what is interesting is what happens to each case.
2. "How do you run one case?" — this checks whether the candidate knows about subtests.
3. "Why t.Parallel, and what can go wrong with it?" — the question where answers diverge the most.
4. "Why did the second go test finish instantly?" — about the cache.
5. "What is wrong with this benchmark?" — the classic problem: the benchmark measures the wrong thing.
6. "How do you test code with external dependencies?" — about interfaces and fakes.

The ladder has one spine: go test is not just calling functions one after another. It has its own order of execution, its own cache and its own relationship with the compiler, and almost every mistake comes from assuming that order is obvious.

Base: a table-driven test is subtests

The function under test and its table:

func TestClamp(t *testing.T) {
	tests := []struct {
		name      string
		v, lo, hi int
		want      int
	}{
		{"inside", 5, 0, 10, 5},
		{"below", -3, 0, 10, 0},
		{"above", 42, 0, 10, 10},
		{"at_boundary", 10, 0, 10, 10},
	}
	for _, tc := range tests {
		t.Run(tc.name, func(t *testing.T) {
			if got := Clamp(tc.v, tc.lo, tc.hi); got != tc.want {
				t.Errorf("Clamp(%d, %d, %d) = %d, want %d", tc.v, tc.lo, tc.hi, got, tc.want)
			}
		})
	}
}

t.Run turns each case into a subtest named TestClamp/<name>. A subtest has its own result, its own line in the report — and it can be run on its own:

  go test -v ./cases/table/
  --- PASS: TestClamp
      --- PASS: TestClamp/inside
      --- PASS: TestClamp/below
      --- PASS: TestClamp/above
      --- PASS: TestClamp/at_boundary
  go test -v -run 'TestClamp/above' ./cases/table/
  --- PASS: TestClamp
      --- PASS: TestClamp/above

A junior-level answer: a table-driven test is a slice of cases and one check in a loop; each case is run via t.Run so that it has a name, a separate result and can be run on its own with -run. t.Errorf reports a failure and lets the test carry on; t.Fatalf stops the current test.

Mechanism 1: a parallel subtest waits for the parent to finish

t.Parallel() does not say "run me now in a separate goroutine" but something else:

"Only with" is the key. A subtest that called t.Parallel() is paused and waits until the parent's body finishes: only then do the parallel subtests run together. And the parent's body has a defer, which fires at exactly that moment. The same test with a resource closed in two ways:

2) PARALLEL SUBTESTS: defer VERSUS t.Cleanup
────────────────────────────────────────────
  EVENT defer: resource opened
  EVENT defer: parent body finished
  EVENT defer: resource closed
  EVENT defer: subtest a runs, resource closed: true
  EVENT defer: subtest b runs, resource closed: true
  EVENT Cleanup: resource opened
  EVENT Cleanup: parent body finished
  EVENT Cleanup: subtest a runs, resource closed: false
  EVENT Cleanup: subtest b runs, resource closed: false
  EVENT Cleanup: resource closed

With defer both subtests got a closed resource: a database connection, a temporary directory, a test server. The test may even pass — for example, if the subtest does not check the closed connection's error.

t.Cleanup is built for this case:

Hence the rule: a parent's resource used by parallel subtests is released through t.Cleanup, not the parent's defer. Built-in helpers such as t.TempDir() work the same way: the directory is removed in a Cleanup.

This is about the parent's defer specifically. A defer inside the subtest itself fires when the subtest's body finishes — after its work — and for a resource the subtest created for itself it is fine. And there is a second way to wait for parallel subtests — a group:

t.Run("group", func(t *testing.T) {
	for _, name := range []string{"a", "b"} {
		t.Run(name, func(t *testing.T) {
			t.Parallel()
			// work with the shared resource
		})
	}
})
// execution gets here once the group's subtests have finished

1) A t.Run GROUP AND defer INSIDE A SUBTEST
───────────────────────────────────────────
  EVENT group: resource opened
  EVENT group: subtest a is running, resource closed: false
  EVENT group: subtest b is running, resource closed: false
  EVENT group: the group returned, resource closed
  EVENT local: subtest a is running, its own resource closed: false
  EVENT local: subtest a closed its own resource
  EVENT local: subtest b is running, its own resource closed: false
  EVENT local: subtest b closed its own resource

Both subtests of the group saw the resource open, and ordinary code after t.Run("group", …) closed it. Each subtest's local defer fired after that subtest's work (a run of bench/gotest/boundaries.go, section 1).

Mechanism 2: the loop variable is a matter of the go line in go.mod

The classic bug of parallel subtests is a closure over the loop variable. Since Go 1.22 the specification says:

But which semantics applies is decided not by the compiler version but by the module's language version — the go line in go.mod. One and the same test, one and the same go1.24.7 compiler, two modules:

cases := []string{"a", "b", "c"}
for _, tc := range cases {
	t.Run(tc, func(t *testing.T) {
		t.Parallel()
		fmt.Printf("EVENT subtest %s sees tc = %s\n", t.Name(), tc)
	})
}

3) THE LOOP VARIABLE IN PARALLEL SUBTESTS
─────────────────────────────────────────
  module with go 1.21 in go.mod:
  EVENT subtest TestCases/a sees tc = c
  EVENT subtest TestCases/b sees tc = c
  EVENT subtest TestCases/c sees tc = c
  module with go 1.24 in go.mod — the same code:
  EVENT subtest TestCases/a sees tc = a
  EVENT subtest TestCases/b sees tc = b
  EVENT subtest TestCases/c sees tc = c
  go vet in the module with go 1.21:
  loopvar/loopvar_test.go:16:73: loop variable tc captured by func literal

In the old module all three subtests checked the last case of the table — and the test passed: the bug is not in the result but in two thirds of the table never being checked at all. It is Mechanism 1 at work: the subtests wait until the parent's loop finishes, and by then the single variable tc holds the last value.

The practical takeaway for an interview: "Go 1.22 fixed this" is only half right. A module whose go.mod declares an older version keeps the old semantics even on a new compiler. The line tc := tc in old code is not clutter but protection; go vet in such a module catches its absence.

Mechanism 3: how many subtests run at once

"t.Parallel means all subtests at once" is a natural expectation. But the number of simultaneous tests is limited by a flag:

Four subtests sleeping 200 ms each, all with t.Parallel():

4) HOW MANY SUBTESTS RUN AT ONCE
────────────────────────────────
  four subtests sleeping 200 ms each, all with t.Parallel()
  -parallel by default (= GOMAXPROCS)       404 ms
  -parallel=1                               805 ms
  -parallel=4                               203 ms

Sleeping does not occupy the processor, but the flag limits the number of subtests, not the load on cores: on a machine with GOMAXPROCS=2, subtests waiting on a network or a database run in pairs. If such tests are slow, -parallel is raised explicitly. And the reverse: on a CI machine with many cores more parallel tests will run — and those sharing a resource will start getting in each other's way.

Mechanism 4: a repeated go test does not run the tests

5) THE RESULT CACHE
───────────────────
  go test ./cases/table/
  ok  deepengineering/bench/gotest/cases/table
  go test ./cases/table/
  ok  deepengineering/bench/gotest/cases/table  (cached)
  go test -count=1 ./cases/table/
  ok  deepengineering/bench/gotest/cases/table

The second run executed nothing:

The cache applies when neither the test binary, nor the flags from a short "cacheable" list, nor the files within the module and the environment variables the test read have changed. That is all go test sees: the state of a database, an external API or files outside the module is not part of the check. For a test that talks to a real database or network this is a trap: a "green" result may have been taken an hour ago, before the database changed. That is why integration tests are run with -count=1 — the idiomatic way to disable the cache.

Mechanism 5: t.Fatal in a goroutine, t.Setenv and synthetic time

t.Fatal stops a goroutine, not the test. t.Fatalf is t.Errorf plus t.FailNow, and that one works like this:

runtime.Goexit ends the goroutine that called it. If that is a goroutine the test started, that goroutine stops — and the test carries on:

3) t.Fatal FROM ANOTHER GOROUTINE
─────────────────────────────────
  fatalgo_test.go:16: error in the goroutine
  EVENT fatalgo: the test keeps working after t.Fatal
  --- FAIL: TestFatalFromGoroutine (0.00s)
  go vet:
  cases/fatalgo/fatalgo_test.go:16:3: call to (*testing.T).Fatal from a non-test goroutine

The test is marked failed, but the code after waiting for the goroutine ran — what t.Fatal was supposed to prevent happened. The documentation requires calling FailNow only from the test's own goroutine, and go vet catches such a call. From goroutines the test started, an error is passed back over a channel or reported with t.Errorf: the Log and Error families may be called from several goroutines.

t.Setenv and t.Chdir are incompatible with t.Parallel. Environment variables and the current directory are shared by the whole process:

This is not advice but a check: the package panics.

2) t.Setenv IN A PARALLEL TEST
──────────────────────────────
  --- FAIL: TestSetenvParallel (0.00s)
  panic: testing: test using t.Setenv or t.Chdir can not use t.Parallel [recovered]

Time in tests is substituted — testing/synctest. Code inside a synctest.Run "bubble" lives by a synthetic clock: time moves forward when every goroutine in the bubble is blocked. A sleep of a whole day:

4) testing/synctest (GOEXPERIMENT=synctest)
───────────────────────────────────────────
  EVENT synctest: 24h0m0s passed inside the bubble
  EVENT synctest: less than a second passed on the real clock: true

Tests of timeouts, retries and tickers stop waiting for real and stop depending on how loaded the machine is. In an interview an honest answer about synctest includes the version: in go1.24.7 it is an experiment.

Deeper: a benchmark that measures an empty loop

A classic interview problem — "what is wrong with this benchmark":

func BenchmarkDiscard(b *testing.B) {
	for i := 0; i < b.N; i++ {
		work(i)
	}
}

work is a pure function, a few multiplications and shifts. Nobody needs the result. The compiler inlines the call and sees that its result is unused — and there is no reason to compute it:

  BenchmarkDiscard     0.32 ns/op
  BenchmarkSink        1.65 ns/op
  BenchmarkLoop        2.20 ns/op
  Sink / Discard: 5.2
  Best of 5 runs. What the compiler decided (-gcflags=-m):
  bench_test.go:41:2: skip inlining within testing.B.loop for for loop
  bench_test.go:27:7: inlining call to work

BenchmarkDiscard measured an empty loop. This is not a general rule that "any benchmark with a discarded result is empty": the computation was thrown away because work is pure and was inlined — after inlining the compiler sees that nobody needs the result. What it decided in a particular case is shown by -gcflags=-m, not by a guess. Two ways to protect the measurement:

• b.Loop() (Go 1.24) — the way for new code: the compiler does not throw away calls to functions in the body of a for b.Loop() { ... } loop.
• Keep the result in a package-level variable: sink = work(i) — 1.65 ns. It is the old technique from before b.Loop; worth recognising in existing code.

The boundary of the promise is in the same documentation: in functions called by the loop, optimisations are performed as usual. How the compiler keeps the promise is a property of the version:

The -gcflags=-m output shows how it achieves this in go1.24.7: inside b.Loop the call is not inlined (skip inlining within testing.B.loop). Hence 2.20 ns against 1.65: b.Loop also measures the function call itself. Neither variant is "right" in general — they measure slightly different things, and in an interview the ability to say so is exactly what is valued.

And one last thing — about the numbers themselves. "Best of N" is good for an order-of-magnitude estimate, but not enough to conclude "it got faster": one lucky run says nothing about the spread. Ten runs of the same benchmarks:

5) BENCHMARK SPREAD: TEN RUNS
─────────────────────────────
                          min   median      max
  BenchmarkDiscard       0.33     0.34     0.42   ns/op, 10 runs
  BenchmarkSink          1.61     1.76     1.95   ns/op, 10 runs
  "Best of N" throws the spread away. Conclusions about speed
  compare distributions of series — that is what benchstat does.

To compare "before and after", a benchmark is run in series (-count=10) and the series are compared with the benchstat tool from golang.org/x/perf: it shows the centre of a series, the spread and whether the difference is significant.

How to answer in an interview

Short answer: a test is a function TestXxx(t *testing.T); a table-driven test is a slice of cases and one check in a loop; each case is a t.Run subtest and can be run on its own with -run. t.Parallel runs subtests in parallel, and shared resources must be released through t.Cleanup. Races are hunted with go test -race, the cache is bypassed with -count=1.

That is enough for a correct answer. What follows is what you add if the interviewer digs.

If the interviewer digs deeper

On "what can go wrong with t.Parallel" — the order. "A parallel subtest waits until the parent's body finishes. The parent's defer fires before the subtests — in my run both subtests got a closed resource. So t.Cleanup, not the parent's defer — or a group: t.Run does not return until its parallel subtests have finished."

On the loop variable — go.mod. "Since Go 1.22 each iteration has its own variable, but only in modules whose go.mod declares 1.22 or later. In a module with go 1.21 on go1.24.7 all parallel subtests saw the last case."

On "why didn't the tests speed up" — -parallel. "No more run at once than -parallel, and that defaults to GOMAXPROCS. Four sleeping subtests with GOMAXPROCS=2 — 404 ms, not 200."

On "what is wrong with the benchmark" — the discarded result. "Nobody needs the result of the pure inlined function, and the compiler threw the computation away: 0.32 ns is an empty loop. Check with -gcflags=-m. In new code — for b.Loop(); the old technique is keeping the result in a package variable. And compare series with benchstat, not the best run."

On "the second run was instant" — the cache. "That is (cached): the tests did not run. The cache knows nothing about the state of databases and external services, so integration tests run with -count=1."

Next they ask

Common misconceptions

Practice

Two problems. Answer first, then check against the real output: in both, the correct answer is taken from a run of the script rather than assigned.

func TestDB(t *testing.T) {
defer fmt.Println("defer: closed")
t.Cleanup(func() { fmt.Println("Cleanup: closed") })
t.Run("a", func(t *testing.T) {
	t.Parallel()
	fmt.Println("subtest a")
})
fmt.Println("end of body")
}

end of body
defer: closed
subtest a
Cleanup: closed

subtest a
end of body
defer: closed
Cleanup: closed

end of body
subtest a
defer: closed
Cleanup: closed

subtest a
end of body
Cleanup: closed
defer: closed

Knowledge check