How do you test Go code?

Question

Accepted Answer

Go has **built-in testing** via the `testing` package and the `go test` command — no external framework needed. Tests live in `_test.go` files, and Go strongly emphasizes **table-driven tests**, benchmarks, and good tooling as first-class features.

## A basic test

```go
// math.go
func Add(a, b int) int { return a + b }

// math_test.go — same package, _test.go suffix
import "testing"

func TestAdd(t *testing.T) {     // Test prefix + *testing.T parameter
    result := Add(2, 3)
    if result != 5 {
        t.Errorf("Add(2,3) = %d; want 5", result)   // report failure (continues)
        // t.Fatalf stops the test immediately
    }
}
// run with: go test  (or `go test -v` for verbose, `go test ./...` for all packages)
```

A test function starts with `Test`, takes `*testing.T`, and reports failures via `t.Errorf`/`t.Fatalf`. There are no assertion keywords — you check conditions with plain `if` and report failures (Go favors this explicit style).

## Table-driven tests — the idiomatic Go pattern

```go
func TestAdd(t *testing.T) {
    tests := []struct {           // a table of test CASES
        name     string
        a, b     int
        expected int
    }{
        {"positives", 2, 3, 5},
        {"with zero", 0, 5, 5},
        {"negatives", -1, -1, -2},
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {     // a SUBTEST per case (named, isolated)
            if got := Add(tt.a, tt.b); got != tt.expected {
                t.Errorf("Add(%d,%d) = %d; want %d", tt.a, tt.b, got, tt.expected)
            }
        })
    }
}
```

**Table-driven tests** are the dominant Go idiom — define a slice of cases, loop over them with `t.Run` subtests. This makes adding cases trivial and gives clear, individual pass/fail reporting per case.

## Benchmarks — built-in performance testing

```go
func BenchmarkAdd(b *testing.B) {
    for i := 0; i < b.N; i++ {     // the framework chooses b.N for statistical accuracy
        Add(2, 3)
    }
}
// go test -bench=. → reports ns/op (and -benchmem for allocations)
```

## Coverage and other tooling

```bash
go test -cover                    # coverage percentage
go test -coverprofile=c.out       # then: go tool cover -html=c.out (visual report)
go test -race                     # the RACE DETECTOR — finds data races (crucial for concurrency)
go test -run TestAdd              # run specific tests
```

The **`-race` flag** is especially important — it detects data races in concurrent code, a key tool given Go's concurrency focus.

## Test helpers and setup

```go
func TestMain(m *testing.M) {     // package-level setup/teardown
    setup()
    code := m.Run()
    teardown()
    os.Exit(code)
}
// t.Helper() marks a function as a test helper (better failure line reporting)
// httptest package for testing HTTP handlers; interfaces for mocking dependencies
```

## Why it matters

Testing is a first-class, built-in part of Go — the `testing` package and `go test` require no external framework, reflecting Go's emphasis on testing as a core practice.

Understanding the conventions is essential everyday knowledge: the `_test.go` file and `TestXxx(t *testing.T)` structure, the explicit (assertion-less) failure-reporting style, and especially the **table-driven test** pattern that dominates idiomatic Go (compactly covering many cases with clear per-case reporting via subtests).

Equally important are Go's built-in **benchmarks** (performance as a testable concern) and the powerful **tooling** — coverage analysis and particularly the **`-race` detector**, which finds data races in concurrent code (vital given Go's concurrency-heavy use).

Knowing how to write effective, idiomatic Go tests, use the race detector, and leverage `httptest`/interfaces for testing real components is a hallmark of professional Go development and a frequent topic reflecting code-quality fluency.