Practical guide
Give a fuzzer a failure it can recognize
A fuzzer explores inputs faster than a person can write them. It still needs a test that can distinguish an unacceptable result from a valid one.
Choose an oracle before a run budget
A parser that never panics can still accept invalid input or return the wrong value. A target should check a requirement: rejection leaves state unchanged, accepted values satisfy an invariant, or a round trip preserves intended information. Coverage guidance helps reach code but supplies no business expectation. The Go fuzzing documentation explains exploration, deterministic targets and failure minimization.
Illustrative harness: a record codec
For each generated byte string:
decode with the production parser
if rejected: assert persistent state is unchanged
if accepted:
encode the parsed value
decode the encoding
assert semantic equality with the first parsed value
This is harness pseudocode. Define semantic equality: ordering may be irrelevant while duplicate keys or numeric precision matter. A round trip can miss compensating bugs in encoder and decoder, so keep independent examples with expected values.
Select one target and its package
Implement a deterministic FuzzDecodeRecord test. Seed valid, malformed and boundary records. Keep per-input state isolated so a failure replays.
go test -run='^$' -fuzz='^FuzzDecodeRecord$' -fuzztime=30s ./internal/record
The target and path are illustrative. This exploratory command skips ordinary test selection; run the normal suite separately. Thirty seconds is a budget, not a completeness claim.
Retain the discovery
Preserve the minimized input, exact assertion, revision and replay command. Establish that it reaches the supported API rather than a test-only shortcut. Fix behavior or explicitly revise the requirement, then retain the case as a regression. In Proof, connect it to the affected requirement or known issue. A corpus file's presence does not report a passing execution.
Explain the limits of a clean campaign
Name the target, environment, duration and exclusions. A clean campaign means no chosen oracle failed for the inputs executed in that run. It does not prove universal correctness, complete branch coverage or MC/DC independence. If the harness never reaches the risky code, a high execution count supplies little evidence about that risk.
Follow the evidence
Improve one fuzz assertion before increasing its run budget.
Review one fuzz target. Bring the harness, oracle and a representative input so we can assess whether a meaningful product failure would actually be detected.