golang-testing

Go Benchmark-Driven Optimization and Fuzzing

Table-driven unit tests answer "is this correct." This skill answers two different questions: "is this fast enough, and did my change actually help" (benchmarks), and "does this hold for inputs I didn't think to write a test case for" (fuzzing). Reach for go-service-idioms or test-driven-development for ordinary correctness tests first — only bring in benchmarks once a performance question is on the table, and fuzzing once a function parses or validates untrusted/varied input.

Writing a benchmark

func BenchmarkProcess(b *testing.B) {
    data := generateTestData(1000)
    b.ResetTimer() // exclude setup cost above from the measured loop
    for i := 0; i < b.N; i++ {
        Process(data)
    }
}

Run with -benchmem always — throughput (ns/op) without allocation counts (B/op, allocs/op) hides regressions where a change got faster per-op but started allocating more, which shows up as GC pressure under real load:

go test -bench=BenchmarkProcess -benchmem ./...
# BenchmarkProcess-8   10000   105234 ns/op   4096 B/op   10 allocs/op

Sub-benchmarks to compare alternatives directly

Use b.Run to benchmark several implementations side by side in one invocation, so the comparison runs under identical conditions:

func BenchmarkJoin(b *testing.B) {
    parts := []string{"hello", "world", "foo", "bar", "baz"}

    b.Run("plus_concat", func(b *testing.B) {
        for i := 0; i < b.N; i++ {
            var s string
            for _, p := range parts {
                s += p
            }
            _ = s
        }
    })

    b.Run("strings_builder", func(b *testing.B) {
        for i := 0; i < b.N; i++ {
            var sb strings.Builder
            for _, p := range parts {
                sb.WriteString(p)
            }
            _ = sb.String()
        }
    })
}

This is how a claim like "strings.Builder is faster than += in a loop" (see golang-patterns) gets verified rather than taken on faith — run both, read the numbers, don't guess.