What this prompt does
This prompt writes a comprehensive, idiomatic Go test suite for a package rather than a handful of happy-path checks. You set [package_type] and [package_purpose], and the AI produces table-driven tests with t.Run subtests for [function_count] functions, test helpers marked with t.Helper(), and interface-based mocking using plain mock structs instead of external libraries. Table-driven tests with subtests are how you keep handler regressions out of production while keeping the test code itself readable and easy to extend.
The variables target the realistic parts of Go testing that people skip. [assertion_style] chooses between testify and plain stdlib comparisons, [golden_use_case] sets up golden-file snapshot testing to catch output and API drift, and [benchmark_targets] and [fuzz_targets] add benchmarks and Go's built-in fuzzing for the hot paths and the untrusted inputs respectively. The prompt also covers parallel tests with t.Parallel() where it is genuinely safe, testdata/ fixtures, and integration tests separated cleanly by the //go:build integration build tag, following standard Go conventions throughout.
When to use it
- Hardening a Go service before it ships to production
- Generating table-driven tests with subtests for a package's exported functions
- Setting up golden-file snapshots to catch API response or output drift early
- Adding benchmarks and fuzz tests for parsing and validation code paths
- Writing interface-based mocks without pulling in a heavy mocking framework
- Separating slow integration tests behind a build tag so unit runs stay fast
Example output
You get a test file or files with table-driven tests using t.Run subtests, t.Helper()-marked helpers for [helper_types], and mock structs implementing the relevant interfaces by hand. It includes golden-file tests for your [golden_use_case], benchmarks for the hot paths, Go fuzz tests for the [fuzz_targets], parallel tests where safe, testdata/ fixtures, and integration tests gated behind //go:build integration, plus the exact go test commands for each different scenario. The mock structs satisfy the package's interfaces directly, so you can inject failures and edge conditions without standing up real dependencies during the unit tests.
Pro tips
- Describe
[package_purpose]precisely so the generated test cases cover real behavior rather than stubs - Keep
[function_count]aligned with the package's actual exported surface to avoid padding the suite - Prefer stdlib
[assertion_style]for portability unless your team already standardizes on testify everywhere - Use golden files for
[golden_use_case]like JSON responses, and regenerate them deliberately, not on every diff - Mark fuzz
[fuzz_targets]on inputs that parse untrusted data; that is where fuzzing genuinely pays off - Put shared fixtures in testdata/ and load them through your
[helper_types]so test setup stays consistent and readable - Only add t.Parallel() where tests truly share no mutable state, or you will trade flakiness for a little speed
