go-testing-patterns

name	go-testing-patterns
description	Guides expert-level Go testing: table-driven tests, testify assertions, httptest for HTTP handlers, integration test patterns, benchmarks, and fuzz testing. Use when the user asks about Go testing, table-driven tests, testify, httptest, benchmarks, fuzz testing, Go test organization. Do NOT use when the user asks about Go project setup (use `go-project-setup`), Go idioms (use `go-idioms`), general testing concepts (use `unit-testing-patterns`).
license	Apache-2.0
metadata	{"author":"foundry-skills","version":"1.0.0","tags":"go testing tdd","category":"software-engineering","subcategory":"languages-runtimes","depends":"","disclaimer":"none","difficulty":"intermediate"}

Go Testing Patterns

When to Use

Use this skill when:

• The user asks how to structure test files, test functions, or test packages in a Go project
• The user asks about table-driven tests, subtests, or parameterized testing in Go
• The user asks about the testify library (assert, require, mock, suite) or whether to use it over stdlib
• The user asks about testing HTTP handlers or middleware using net/http/httptest
• The user asks about writing benchmarks with testing.B, profiling benchmarks, or avoiding benchmark optimizations that skew results
• The user asks about fuzz testing with testing.F (Go 1.18+), seed corpus, or fuzz targets
• The user asks about integration tests, test helpers, TestMain, or golden files in Go
• The user asks about race condition detection, parallel tests, or coverage thresholds in Go CI

Do NOT use this skill when:

• The user asks about initializing a Go module, project layout, or go.mod configuration -- use go-project-setup
• The user asks about Go idioms, error handling conventions, or interface design -- use go-idioms
• The user asks about general unit testing theory, TDD philosophy, or test pyramid concepts without Go specifics -- use unit-testing-patterns
• The user asks about Go concurrency patterns without a testing focus -- use go-concurrency
• The user asks about CI/CD pipeline configuration that happens to run Go tests -- use ci-cd-pipelines
• The user asks about load testing or performance profiling in production -- use performance-profiling

---

Process

1. Identify the Test Category and Appropriate Pattern

Classify what is being tested before writing a single line of test code. Each category has a canonical Go approach.

• Pure functions with no side effects: Standard table-driven tests using t.Run subtests. No mocking required. Focus on boundary values, zero values, and error paths.
• Methods on structs with injected dependencies: Interface-based fakes or testify/mock. Inject via constructor, never via init() or package-level globals.
• HTTP handlers and middleware: Use net/http/httptest.NewRecorder() for handler-level tests and httptest.NewServer() for full integration roundtrips including middleware chains.
• Database-touching code: Use a real test database (ephemeral Docker container via ory/dockertest or testcontainers-go) or a recorded query replay tool. Never use SQLite as a substitute for Postgres -- schema differences cause false confidence.
• File system or OS interaction: Use t.TempDir() (Go 1.15+) which automatically cleans up after the test. Never hardcode /tmp/ paths.
• CLI commands: Use os/exec with a compiled binary in TestMain, or restructure the command logic to accept an io.Writer for output so it can be tested without subprocess overhead.
• Concurrent or goroutine-based code: Always run with -race. Use channels or sync.WaitGroup to synchronize, never time.Sleep.

2. Set Up the Test File Structure

Go test files have strict conventions that must be respected.

• Place test files in the same package as the code under test (whitebox testing: package mypackage) to access unexported identifiers, OR in a _test package (blackbox testing: package mypackage_test) to enforce API boundary discipline. Prefer _test suffix packages for exported APIs; use internal packages for unexported logic testing.
• Name the test file {filename}_test.go. Go tooling will not compile these files outside of go test.
• Use internal/testhelpers or a dedicated testutil package for shared helper functions. Export helpers from this package, not from production packages.
• Never put test helpers in _test.go files if they need to be shared across packages -- _test.go files are not importable by other packages.
• Place integration tests in a separate integration/ directory or gate them behind a build tag: //go:build integration. Run them separately in CI: go test -tags=integration ./....
• Use TestMain(m *testing.M) only when you need true global setup/teardown (starting a database container, compiling a binary, seeding shared fixtures). Call os.Exit(m.Run()) at the end -- failing to do so causes the test binary to report success regardless of test outcomes.

3. Write Table-Driven Tests with Subtests

Table-driven tests are idiomatic Go. Apply this pattern consistently for any function that processes varied inputs.

• Define a slice of anonymous structs (not a map -- maps have non-deterministic iteration order) containing: name string, input fields, expected output fields, and wantErr bool or a specific error type check.
• Use t.Run(tc.name, func(t *testing.T) { ... }) for each case. This produces output like --- FAIL: TestParseURL/empty_host which is grep-friendly.
• Mark subtests as parallel with tt := tc; t.Parallel() inside the subtest closure. Assign the loop variable to a local copy (tt) before calling t.Parallel() -- failing to do so is the classic Go loop variable capture bug that was fixed only in Go 1.22. For Go < 1.22, this copy is mandatory.
• Name test cases with snake_case or short descriptive phrases: "empty_input", "max_int_boundary", "unicode_multibyte_sequence". Avoid "test 1", "case A", or numeric-only names.
• Group cases that test error conditions at the end of the table. Arrange happy-path cases first for readability.
• For functions returning error, always include at least one case where wantErr: true and verify error content -- not just err != nil.

func TestParseAmount(t *testing.T) {
    t.Parallel()
    tests := []struct {
        name    string
        input   string
        want    int64
        wantErr bool
    }{
        {name: "valid_integer", input: "100", want: 100},
        {name: "leading_zeros", input: "007", want: 7},
        {name: "empty_string", input: "", wantErr: true},
        {name: "negative_value", input: "-5", wantErr: true},
        {name: "overflow_int64", input: "99999999999999999999", wantErr: true},
    }
    for _, tc := range tests {
        tc := tc // pre-1.22 capture fix
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            got, err := ParseAmount(tc.input)
            if tc.wantErr {
                if err == nil {
                    t.Fatalf("expected error, got nil")
                }
                return
            }
            if err != nil {
                t.Fatalf("unexpected error: %v", err)
            }
            if got != tc.want {
                t.Errorf("got %d, want %d", got, tc.want)
            }
        })
    }
}

4. Choose Between stdlib Assertions and testify

The stdlib provides t.Error, t.Errorf, t.Fatal, and t.Fatalf. Testify provides assert and require packages. Make a deliberate choice per project and stick to it.

• Use stdlib only when the project has zero external test dependencies, when assertions are simple equality or nil checks, and when the team is comfortable with verbose error messages.
• Use testify/assert when you need rich diff output for struct comparisons, when you want to continue running the rest of a test after a failure (non-fatal assertions), or when testing teams find the assert.Equal(t, expected, actual) signature more readable.
• Use testify/require (same API as assert) when a failure means the test cannot meaningfully continue -- e.g., require.NoError(t, err) before using a value that err guards. require calls t.FailNow() which stops the current test immediately; assert calls t.Fail() which marks failure but continues execution.
• The argument order convention for testify is (t, expected, actual) -- putting expected first matches the error message format "expected X, got Y". Getting this backwards is a common mistake that produces confusing failure messages.
• Use testify/mock for interface mocking. Define a struct that embeds mock.Mock, implement the interface methods calling m.Called(args...), and set up expectations with mockObj.On("MethodName", args).Return(values). Always call mockObj.AssertExpectations(t) at the end of each test that uses a mock.
• Do NOT use testify/suite for new code. Suites add SetupTest/TeardownTest lifecycle hooks but obscure test structure, make parallelism awkward, and create hidden coupling between tests. Use explicit helper functions and t.Cleanup() instead.

5. Test HTTP Handlers with httptest

The net/http/httptest package is the canonical tool for testing Go HTTP code without a real server.

• Use httptest.NewRecorder() for testing a single handler function. Create the recorder, create a request with http.NewRequest("GET", "/path", nil), call handler.ServeHTTP(rec, req), then inspect rec.Code, rec.Body.String(), and rec.Header().
• Use httptest.NewServer(handler) to spin up a real TCP listener on a random port. This is required when testing middleware chains, redirect behavior, connection-level behavior, or client code that needs a real URL. Call defer ts.Close() immediately after creating the server.
• Use httptest.NewTLSServer(handler) when testing TLS-specific behavior. The returned server uses a self-signed certificate; access it with ts.Client() which is pre-configured to trust it.
• When testing a router (e.g., chi, gorilla/mux, stdlib ServeMux), pass the fully assembled router to httptest.NewRecorder() or httptest.NewServer(). Do not test routes in isolation from the router -- the routing is part of the contract.
• Set request headers explicitly: req.Header.Set("Content-Type", "application/json"). Missing content-type headers cause handler failures that are not obvious from the test output.
• For authenticated endpoints, add an auth header or cookie to the request in the test. Create a test helper func newAuthRequest(t *testing.T, method, path string) *http.Request to avoid repetition.
• Parse and validate response bodies with json.NewDecoder(rec.Body).Decode(&result) -- do not use string matching on JSON unless testing exact serialization format.

func TestCreateUserHandler(t *testing.T) {
    svc := &fakeUserService{createResult: &User{ID: "u1", Email: "[e-mail]"}}
    h := NewUserHandler(svc)

    body := `{"email":"[e-mail]","password":"secret123"}`
    req := httptest.NewRequest(http.MethodPost, "/users", strings.NewReader(body))
    req.Header.Set("Content-Type", "application/json")
    rec := httptest.NewRecorder()

    h.ServeHTTP(rec, req)

    require.Equal(t, http.StatusCreated, rec.Code)
    var resp UserResponse
    require.NoError(t, json.NewDecoder(rec.Body).Decode(&resp))
    assert.Equal(t, "u1", resp.ID)
    assert.Equal(t, "[e-mail]", resp.Email)
}

6. Write Benchmarks Correctly

Benchmarks in Go use testing.B and are invoked with go test -bench=. -benchmem. Common mistakes produce meaningless results.

• Name benchmark functions BenchmarkXxx where Xxx describes the operation: BenchmarkJSONMarshal_SmallStruct, BenchmarkQueryUser_CacheMiss.
• The benchmark loop must use b.N exactly: for i := 0; i < b.N; i++ { ... }. The testing framework calibrates b.N automatically until the benchmark runs for at least 1 second by default.
• Call b.ResetTimer() after expensive setup that should not be measured: allocating large data structures, connecting to test databases, or parsing large files. Do NOT call b.ResetTimer() inside the benchmark loop.
• Use b.ReportAllocs() or run with -benchmem to see allocation counts per operation (allocs/op). Reducing allocs/op to zero for hot paths is often more impactful than CPU time improvements.
• Prevent compiler dead-code elimination by assigning results to a package-level variable of the appropriate type: var BenchResult SomeType. Inside the benchmark loop: BenchResult = result. Without this, the compiler may optimize away the work being measured.
• Use b.RunParallel to benchmark concurrent workloads: this runs the benchmark body in parallel goroutines proportional to GOMAXPROCS. Use it to detect lock contention.
• Use benchstat (from golang.org/x/perf/cmd/benchstat) to compare benchmark runs statistically. Run each benchmark at least 5-10 times (-count=10) before comparing with benchstat old.txt new.txt.

7. Write Fuzz Tests (Go 1.18+)

Fuzz testing uses testing.F and the go test -fuzz flag to generate novel inputs and find panics or invariant violations.

• Name fuzz functions FuzzXxx. The function signature is func FuzzXxx(f *testing.F).
• Provide seed corpus with f.Add(value1, value2, ...). Seeds serve two purposes: they run as regular unit test cases during go test (without -fuzz), and they seed the fuzzer's input generation. Provide at least 3-5 seeds covering boundary conditions.
• The fuzz target is a closure passed to f.Fuzz(func(t *testing.T, arg1 type1, arg2 type2) { ... }). Keep the fuzz target simple and deterministic -- avoid network calls, sleep, or goroutines inside it.
• The fuzzer saves inputs that cause failures to testdata/fuzz/FuzzXxx/ as files. Commit these files to the repository -- they become permanent regression tests run on every go test invocation.
• Check invariants inside the fuzz target, not just absence of panics. For a parser: parsed, err := Parse(input); if err == nil { assert.Equal(t, input, parsed.String()) } verifies a round-trip invariant.
• Run fuzzing in CI with a time limit: go test -fuzz=FuzzParseURL -fuzztime=30s ./pkg/url/. Do not run unlimited fuzzing in CI -- it will never terminate. Run long fuzzing sessions locally or in dedicated fuzzing infrastructure.
• Fuzz targets support only the following argument types: string, []byte, bool, byte, rune, float32, float64, int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64. To fuzz complex structs, encode them as JSON bytes and unmarshal inside the target.

8. Configure Coverage, Race Detection, and CI Integration

Test quality is enforced through tooling, not convention alone.

• Run go test -race ./... in CI unconditionally. The race detector has roughly 5-20x runtime overhead -- acceptable in CI, not for production. It detects data races that -count=1 tests will not reveal because timing varies.
• Run go test -cover ./... to get per-package coverage. Run go test -coverprofile=coverage.out ./... && go tool cover -html=coverage.out locally to visualize uncovered lines.
• Set a coverage threshold in CI using a shell script or tool like go-test-coverage: reject merges below 80% statement coverage for critical packages. Do not set a single threshold for the entire codebase -- generated code, main packages, and test helpers skew the number.
• Exclude generated files from coverage with //go:build ignore or using coverpkg flags carefully. Use grep to strip generated file coverage from the profile before threshold enforcement.
• Cache test results: go test caches results automatically when inputs have not changed. The cache is invalidated by file changes, environment variable changes, and when -count is set. Use -count=1 to force re-run in CI when you need fresh results despite the cache.
• Use go test -timeout 60s ./... in CI. Default timeout is 10 minutes -- too long for fast feedback. Set package-level timeouts and set the global timeout to 120s as an upper bound.
• Golden file tests store expected output in testdata/ files. Use flag.Bool("update", false, "update golden files") and if *update { os.WriteFile(goldenPath, actual, 0644) } to regenerate them. Run go test -run TestGolden -update when expected output intentionally changes.

---

Output Format

When providing Go testing guidance, structure the response as follows:

## Test Strategy for [Component Name]

**Test category:** [unit | integration | benchmark | fuzz]
**Package placement:** [same package (whitebox) | _test suffix (blackbox)]
**External dependencies:** [list: testify/assert, testify/require, testify/mock, httptest, etc.]

---

### Test File: [filename]_test.go

```go
package [package_name][_test]

import (
    "testing"
    // additional imports
)

// --- Helpers and Fakes ---

type fake[Dependency] struct {
    // recorded calls and configured returns
}

func (f *fake[Dependency]) [Method](args) (returns) {
    // minimal fake implementation
}

// --- Unit Tests ---

func Test[Function]_[Scenario](t *testing.T) {
    t.Parallel()

    tests := []struct {
        name    string
        // input fields
        // expected output fields
        wantErr bool
    }{
        {
            name:    "[descriptive_case_name]",
            // populate fields
        },
    }

    for _, tc := range tests {
        tc := tc
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            // arrange
            // act
            // assert
        })
    }
}

// --- Integration Tests (gated by build tag if needed) ---

// --- Benchmarks ---

var Bench[Result] [ResultType] // package-level sink

func Benchmark[Operation]_[Scenario](b *testing.B) {
    // setup (not measured)
    b.ResetTimer()
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        Bench[Result] = [operation]
    }
}

// --- Fuzz Targets ---

func Fuzz[Operation](f *testing.F) {
    f.Add([seed1])
    f.Add([seed2])
    f.Fuzz(func(t *testing.T, input [type]) {
        // call function under test
        // assert invariants
    })
}

Run commands:

Command	Purpose
go test ./...	All unit tests
go test -race ./...	With race detector
go test -run TestX/subcase ./pkg	Single subtest
go test -bench=BenchmarkX -benchmem -count=5 ./pkg	Benchmark with allocations
go test -fuzz=FuzzX -fuzztime=60s ./pkg	Fuzz for 60 seconds
go test -cover -coverprofile=c.out ./...	Coverage report
go test -tags=integration ./...	Integration tests

Coverage target: [X]% statement coverage for this package Race-safe: [yes | no -- explain why not]

---

## Rules

1. **Never use `time.Sleep` in tests.** Sleeping to wait for async operations is nondeterministic and will cause flaky tests in CI. Use `sync.WaitGroup`, channels, or `require.Eventually(t, condition, 2*time.Second, 10*time.Millisecond)` from testify to poll with a timeout and interval.

2. **Always capture the loop variable before calling `t.Parallel()` in Go < 1.22.** The pattern `tc := tc` inside the `for _, tc := range tests` loop is mandatory. In Go 1.22+, loop variable semantics changed and the copy is no longer required, but it does not hurt to include it for compatibility.

3. **Never assert on `err.Error()` string values for error identity.** String comparison is brittle -- error messages change. Use `errors.Is(err, target)` for sentinel errors, `errors.As(err, &target)` for error types, or `require.ErrorContains(t, err, "substring")` only when the message is the specification.

4. **The argument order for testify is `(t, expected, actual)`, never reversed.** Getting this wrong produces failure messages like "expected 42, got 42 (expected and actual are identical)" which is disorienting. Always put the known/hardcoded value first.

5. **Never share mutable state between parallel tests.** Any variable written by one `t.Parallel()` subtest and read by another is a data race. Use `t.Cleanup()` for per-test teardown. Use `sync.Mutex` or channels if shared state is truly necessary -- and question whether it is.

6. **Always call `mockObj.AssertExpectations(t)` at the end of tests using `testify/mock`.** Without this call, mocks with uncalled `On()` expectations will silently pass. Register it immediately after creating the mock: `t.Cleanup(func() { mockObj.AssertExpectations(t) })`.

7. **Never use `init()` to register test dependencies or global state.** `init()` runs in every test binary, creates hidden coupling, and makes test isolation impossible. Use `TestMain` for one-time global setup, and explicit constructors for per-test dependency injection.

8. **Benchmark result variables must be package-level sinks.** Assigning benchmark results to a local variable allows the compiler to eliminate the computation as dead code, producing artificially fast benchmarks. Always use a package-level `var BenchResult T` as the sink.

9. **Fuzz seed corpus must cover error-producing inputs, not just valid inputs.** The fuzzer explores from seeds. If all seeds are valid inputs, the fuzzer starts from a valid state and may never discover parsing edge cases. Include empty strings, maximum-length inputs, control characters, and known-bad inputs as seeds.

10. **Integration tests must be gated by a build tag or an environment variable check, never by file naming alone.** Use `//go:build integration` at the top of integration test files, or check `os.Getenv("RUN_INTEGRATION_TESTS") == "1"` in `TestMain` and call `os.Exit(0)` to skip cleanly. Running integration tests on every `go test ./...` invocation slows local development and creates flaky CI.

---

## Edge Cases

**Go version below 1.18 (no fuzz testing available)**
Fuzz testing with `testing.F` requires Go 1.18+. For older codebases, implement property-based testing using `pgregory.net/rapid` or `leanovate/gopter`. These libraries generate random inputs using strategies similar to Haskell's QuickCheck. If upgrading Go is blocked, migrate fuzz targets to `rapid.Check` patterns and add a comment marking them as candidates for migration to native fuzz once Go is upgraded.

**Testing code that calls `os.Exit` or `log.Fatal`**
Functions that call `os.Exit` cannot be tested normally -- they terminate the test process. The standard Go pattern is the "subprocess test": create a test function `TestFoo_exits(t *testing.T)` that checks `os.Getenv("BE_CRASHER") == "1"` and calls the real function. The main test body re-runs itself as a subprocess with the environment variable set and asserts on the subprocess exit code. This is verbose but correct. A simpler alternative is to refactor the code under test to accept an `exit func(int)` parameter (defaulting to `os.Exit`) that can be replaced in tests.

**Testing code that reads from `os.Stdin` or writes to `os.Stdout`**
Replace direct `os.Stdin`/`os.Stdout` references with `io.Reader`/`io.Writer` parameters in the function signature. In tests, use `strings.NewReader("input data")` and `bytes.Buffer` or `strings.Builder` as the writer. This also makes the code more useful as a library. If the function cannot be refactored, use `os.Pipe()` to create a fake stdin/stdout pair: `r, w, _ := os.Pipe(); os.Stdin = r` then write to `w` from the test goroutine.

**Parallel tests with shared database state**
When running integration tests against a real database in parallel, each parallel test must operate in an isolated schema or transaction. The cleanest pattern is to create a fresh database schema per test using `t.Cleanup(func() { db.Exec("DROP SCHEMA test_xxx CASCADE") })`. An alternative is to wrap each test in a transaction and roll it back: `tx := db.Begin(); t.Cleanup(func() { tx.Rollback() })`. Pass `tx` (not the global `db`) to the code under test. This approach prevents parallel tests from interfering but requires that the code accept an interface rather than a concrete `*sql.DB`.

**Testing code with randomness or time-dependent behavior**
Never call `time.Now()` or `rand.Int()` directly inside testable functions. Instead, inject a `clock` interface with a `Now() time.Time` method (or use `github.com/jonboulle/clockwork`) and a `rand.Source` that can be seeded deterministically. In tests, pass a fixed `time.Time` value and a `rand.NewSource(42)`. This makes time-dependent tests fully deterministic without mocking the standard library, which is not possible without patching.

**Large test fixtures and golden files getting out of sync**
Golden files in `testdata/` drift from actual output as the system evolves, causing failures that are fixed by blindly running `-update` without reviewing diffs. Enforce a `git diff --exit-code testdata/` step in CI after running with `-update` -- the update should produce no changes if golden files are current. Additionally, keep golden files small and focused. If a golden file exceeds 50 lines, the test is asserting too much. Break it into multiple focused assertions or tests.

**Mocking interfaces you do not own (e.g., `http.ResponseWriter`, `sql.DB`)**
The stdlib `http.ResponseWriter` is an interface you can implement directly -- `httptest.ResponseRecorder` does exactly this. For `*sql.DB`, which is a concrete struct, the approach is different: define your own `DBQuerier` interface containing only the methods your code uses, have production code accept `DBQuerier`, and write a fake `DBQuerier` in tests. Never mock `*sql.DB` directly. Libraries like `DATA-DOG/go-sqlmock` provide a mock `database/sql` driver, but they are complex and often over-specify behavior. Prefer a hand-written fake interface.

**Race detector finding races only in tests, not production code**
Sometimes the race detector flags races in test helper code -- goroutines launched in `TestMain`, shared counters in fake implementations, or parallel test setup that writes to a shared map. These are real races even if they only appear in test code. Fix them: protect shared state in fakes with a `sync.Mutex`, use `t.Cleanup` instead of goroutines for teardown, and never write to a map from multiple goroutines without synchronization, even in tests.

---

## Example

**Input:** "I need to write tests for a `PricingService` that calculates order totals. It depends on a `ProductRepository` interface to look up product prices and applies a discount if the order total exceeds $100. I also want a benchmark. How do I structure this in Go?"

---

**Output:**

### Test Strategy for PricingService

**Test category:** unit tests (table-driven), benchmark
**Package placement:** `package pricing_test` (blackbox -- testing exported API)
**External dependencies:** `testify/assert`, `testify/require`, `testify/mock`

---

**File: `pricing_test.go`**

```go
package pricing_test

import (
    "errors"
    "testing"

    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/mock"
    "github.com/stretchr/testify/require"

    "github.com/example/shop/pricing"
)

// --- Fake / Mock for ProductRepository ---

// fakeProductRepo is a hand-written fake that gives us full control
// without the overhead of testify/mock for simple cases.
type fakeProductRepo struct {
    prices map[string]float64
    err    error
}

func (f *fakeProductRepo) GetPrice(productID string) (float64, error) {
    if f.err != nil {
        return 0, f.err
    }
    price, ok := f.prices[productID]
    if !ok {
        return 0, pricing.ErrProductNotFound
    }
    return price, nil
}

// mockProductRepo uses testify/mock for tests that need call verification.
type mockProductRepo struct {
    mock.Mock
}

func (m *mockProductRepo) GetPrice(productID string) (float64, error) {
    args := m.Called(productID)
    return args.Get(0).(float64), args.Error(1)
}

// --- Unit Tests: CalculateTotal ---

func TestPricingService_CalculateTotal(t *testing.T) {
    t.Parallel()

    tests := []struct {
        name       string
        prices     map[string]float64
        orderItems map[string]int // productID -> quantity
        wantTotal  float64
        wantErr    bool
        errTarget  error
    }{
        {
            name:       "single_item_no_discount",
            prices:     map[string]float64{"prod-1": 30.00},
            orderItems: map[string]int{"prod-1": 2},
            wantTotal:  60.00, // 2 * 30.00, under $100 threshold
        },
        {
            name:       "multiple_items_no_discount",
            prices:     map[string]float64{"prod-1": 20.00, "prod-2": 15.00},
            orderItems: map[string]int{"prod-1": 3, "prod-2": 1},
            wantTotal:  75.00, // 60 + 15 = 75, under threshold
        },
        {
            name:       "discount_applied_at_exactly_100",
            prices:     map[string]float64{"prod-1": 50.00},
            orderItems: map[string]int{"prod-1": 2},
            wantTotal:  95.00, // 100 * 0.95 = 95.00 (5% discount)
        },
        {
            name:       "discount_applied_above_100",
            prices:     map[string]float64{"prod-1": 40.00, "prod-2": 35.00},
            orderItems: map[string]int{"prod-1": 2, "prod-2": 1},
            wantTotal:  109.25, // 115 * 0.95 = 109.25
        },
        {
            name:       "zero_quantity_item_excluded",
            prices:     map[string]float64{"prod-1": 50.00, "prod-2": 20.00},
            orderItems: map[string]int{"prod-1": 0, "prod-2": 3},
            wantTotal:  60.00, // only prod-2 counted
        },
        {
            name:       "unknown_product_returns_error",
            prices:     map[string]float64{},
            orderItems: map[string]int{"ghost-prod": 1},
            wantErr:    true,
            errTarget:  pricing.ErrProductNotFound,
        },
        {
            name: "repository_error_propagates",
            prices:     nil, // unused -- err is set
            orderItems: map[string]int{"prod-1": 1},
            wantErr:    true,
        },
        {
            name:       "empty_order_returns_zero",
            prices:     map[string]float64{},
            orderItems: map[string]int{},
            wantTotal:  0.00,
        },
    }

    for _, tc := range tests {
        tc := tc // pre-1.22 loop variable capture
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()

            repo := &fakeProductRepo{prices: tc.prices}
            // Override with a repo-level error for the propagation test.
            if tc.name == "repository_error_propagates" {
                repo.err = errors.New("connection refused")
            }

            svc := pricing.NewPricingService(repo)
            got, err := svc.CalculateTotal(tc.orderItems)

            if tc.wantErr {
                require.Error(t, err)
                if tc.errTarget != nil {
                    assert.True(t, errors.Is(err, tc.errTarget),
                        "expected error %v, got %v", tc.errTarget, err)
                }
                return
            }

            require.NoError(t, err)
            assert.InDelta(t, tc.wantTotal, got, 0.001,
                "total mismatch: got %.2f, want %.2f", got, tc.wantTotal)
        })
    }
}

// --- Interaction Test: verify repository is called exactly once per product ---

func TestPricingService_CalculateTotal_CallsRepoOncePerProduct(t *testing.T) {
    t.Parallel()

    repo := &mockProductRepo{}
    repo.On("GetPrice", "prod-1").Return(20.00, nil)
    repo.On("GetPrice", "prod-2").Return(15.00, nil)
    t.Cleanup(func() { repo.AssertExpectations(t) })

    svc := pricing.NewPricingService(repo)
    _, err := svc.CalculateTotal(map[string]int{"prod-1": 3, "prod-2": 2})
    require.NoError(t, err)

    // AssertExpectations in Cleanup verifies each method was called exactly
    // the number of times specified. No extra assertions needed here.
}

// --- Benchmarks ---

// BenchTotal is the package-level sink to prevent dead-code elimination.
var BenchTotal float64

func BenchmarkPricingService_CalculateTotal_SmallOrder(b *testing.B) {
    repo := &fakeProductRepo{
        prices: map[string]float64{
            "prod-1": 19.99,
            "prod-2": 34.50,
        },
    }
    svc := pricing.NewPricingService(repo)
    order := map[string]int{"prod-1": 2, "prod-2": 1}

    b.ResetTimer()
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        total, _ := svc.CalculateTotal(order)
        BenchTotal = total
    }
}

func BenchmarkPricingService_CalculateTotal_LargeOrder(b *testing.B) {
    const productCount = 100
    prices := make(map[string]float64, productCount)
    order := make(map[string]int, productCount)
    for i := 0; i < productCount; i++ {
        id := fmt.Sprintf("prod-%d", i)
        prices[id] = float64(i+1) * 1.25
        order[id] = 2
    }

    repo := &fakeProductRepo{prices: prices}
    svc := pricing.NewPricingService(repo)

    b.ResetTimer()
    b.ReportAllocs()
    for i := 0; i < b.N; i++ {
        total, _ := svc.CalculateTotal(order)
        BenchTotal = total
    }
}

---

Run commands for this service:

Command	Purpose
go test ./pricing/...	All unit tests
go test -race ./pricing/...	With race detector
go test -run TestPricingService_CalculateTotal/discount_applied ./pricing	Single subtest
go test -bench=BenchmarkPricingService -benchmem -count=10 ./pricing	Benchmarks with allocation data
go test -cover -coverprofile=pricing.out ./pricing/... && go tool cover -func=pricing.out	Coverage by function

Expected coverage target: 90%+ statement coverage for pricing package (it contains the core business logic; coverage gaps here represent untested business rules).

Race-safe: Yes -- the fake and mock implementations are used only within individual subtests. No shared mutable state crosses subtest boundaries.

---

Sample benchmark output to expect:

BenchmarkPricingService_CalculateTotal_SmallOrder-8    2847193   421.3 ns/op   96 B/op   3 allocs/op
BenchmarkPricingService_CalculateTotal_LargeOrder-8      28471  42130 ns/op  9600 B/op  300 allocs/op

If allocs/op scales linearly with productCount (3 allocs per product), the next optimization target is to pre-allocate the result accumulator or reuse a pool. Use benchstat with -count=10 to confirm regressions before and after any optimization change.