How would you write a Go fuzz target for a function that decodes and validates a request?

## Why fuzz a decode-and-validate function at all The function that turns request bytes into a usable value is the one place a service trusts input it did not write. Table tests cover the payloads someone thought of; the interesting failures are the ones nobody imagined - a number where a string belongs, a deeply odd but syntactically legal document, a field present but empty, a byte string that is not valid UTF-8. Coverage-guided fuzzing generates those by mutating seeds and keeping the mutations that reach new code, which is exactly the search a human is bad at. ## The mechanics Go's native fuzzing lives in `testing`. A fuzz target is a function in a `_test.go` file named `FuzzXxx` taking a single `*testing.F`: ``` func FuzzParseCreateUser(f *testing.F) { f.Add([]byte(`{"tenant_id":"acme","email":"[email protected]"}`)) f.Add([]byte(`{"email":"[email protected]"}`)) f.Fuzz(func(t *testing.T, data []byte) { u, err := ParseCreateUser(data) if err != nil { return } if u.Tenant() == "" { t.Fatalf("accepted a request with no tenant: %q", data) } }) } ``` - `f.Add` supplies the **seed corpus**: real inputs the fuzzer mutates. Seeds are also checked into the package's `testdata` directory if you want them shared. - `f.Fuzz` takes a function whose first parameter is `*testing.T`; the remaining parameters are the generated input. They must be one of a fixed set of types - `[]byte`, `string`, `bool`, the sized integer and float types, `byte` and `rune` - so a target for a decoder naturally takes `[]byte`. - The arguments of every `f.Add` call must match the fuzz function's parameters in number and type. ## Choosing the property, which is the whole game The fuzzer only tells you that an assertion failed; you decide what is worth asserting. 1. **It never panics.** Free, and it catches the real class of crash-on-input bugs. But it is satisfied by a parser that accepts every byte string, so on its own it proves very little about validation. 2. **A nil error implies the invariants hold.** This is the property that matters here: if the function claims success, then every rule the rest of the service depends on is true of the value it returned. Assert those rules directly against the returned value - not by calling the same validation function again, which would just be a tautology. 3. **Round-trip properties.** If the value can be re-encoded, decoding the re-encoded form should produce an equal value. Useful when a custom encoding is involved. 4. **Agreement between two implementations.** If a rewrite is in flight, assert old and new agree on accept-or-reject for the same bytes. ## Running it and keeping what it finds Without the `-fuzz` flag, `go test` still executes the target once per seed and per file in the package's `testdata` corpus - so a fuzz target is a normal unit test in CI and costs nothing there. Passing `-fuzz=FuzzParseCreateUser` switches on generation; it matches at most one target per package run, and `-fuzztime` bounds it (otherwise it runs until it fails or you stop it). When an input fails, the fuzzer minimises it and writes the reduced input as a file under `testdata/fuzz/FuzzParseCreateUser/`. That file is source: commit it. Every subsequent plain `go test` replays it, so the bug cannot come back silently. This is the part teams under-use - the corpus is a growing regression suite built out of real defects. ## Limits worth stating Fuzzing is dynamic. It reports failures on inputs it happened to generate; a clean run proves nothing about the paths it never reached. It is also slower and noisier than a table test, so it belongs on a scheduled or nightly job rather than on every pull request, with the discovered corpus carrying the value into the fast test run. And it tests the function you wrote, not the rules you forgot: if the requirement to have a tenant id was never expressed anywhere, no fuzzer will invent it.