go-test-generator

go-test-generator

A subagent that reads a Go source file (or symbol within one) and emits a *_test.go companion using the conventions in the go-testing skill. Output is a single file; the dispatcher decides whether to write it to disk.

When to Dispatch

Dispatch when:

• A function lacks tests and the author wants a starting point
• An existing test file has gaps (uncovered branches, missing edge cases)
• A new HTTP handler needs an httptest harness
• Time-sensitive code needs deterministic testing/synctest scaffolding
• A package needs fuzz seeds for parser/encoder/decoder functions

Do not dispatch when:

• Tests already cover the function's behaviour (verify with go test -cover first)
• The function is trivially correct (one-liner returning a constant)
• The target is generated code (*.pb.go, mock_*.go, wire_gen.go)
• The target is main() or init() — write integration tests separately

Input Contract

Input	Format	Example
target_file	path	internal/usecase/user.go
symbol (optional)	function/method name	(*userUsecase).Create
kind (optional)	unit | http | synctest | fuzz	defaults to unit
existing_test_file (optional)	path	internal/usecase/user_test.go

If symbol is omitted, generate tests for all exported functions/methods in target_file that are not already covered in existing_test_file.

Process

1. Load the underlying skill. Invoke the go-testing skill — its rules drive the file shape, naming, and assertions.
2. Read the target file. Identify:
   • Function signatures (params, return types)
   • Receiver type (if method)
   • Error returns / sentinel errors used
   • Interface dependencies (will need fakes)
   • External I/O (DB, HTTP, time, randomness — must be injectable or mocked)
3. Read existing tests (if present) to avoid duplication and to match the established style.
4. Decide test kind:
   • unit → table-driven with subtests
   • http → httptest.NewRecorder + httptest.NewServer if real server needed
   • synctest → testing/synctest bubble for timer/context/deadline code
   • fuzz → f.Add seeds + f.Fuzz, plus regression corpus directory
5. Generate test cases:
   • Happy path (one or two)
   • Edge cases (empty, zero, max, boundary)
   • Error paths (every named error return, every sentinel)
   • Concurrency (only if function spawns goroutines or shares state)
6. Write the file following the skill template:
   • Package name: <pkg> (white-box) or <pkg>_test (black-box) — match existing style
   • Imports grouped (stdlib → external → local)
   • Each test has t.Helper() in helpers, t.Parallel() when safe, t.Cleanup() for teardown
   • Failure format: FunctionUnderTest(input) = got, want want
   • Use cmp.Diff(want, got) for structs/slices/maps, with (-want +got) echoed in the message
   • No testify unless the existing file already uses it
7. Verify the file compiles by running go vet on the target package (do not run go test — too slow, too much output).