Fuzzing

Canonical guidance

• fuzz boundary-heavy code, not everything
• assert invariants and safety properties
• keep seed corpora small but interesting

Use when

• parsing and decoding
• normalization and round-tripping
• string or byte transforms

Avoid

• fuzzing code with trivial input space
• writing fuzz targets with no meaningful property to check
• replacing ordinary unit tests with fuzzing

Preferred pattern

func FuzzParseDuration(f *testing.F) {
	f.Add("5s")

	f.Fuzz(func(t *testing.T, s string) {
		_, _ = time.ParseDuration(s)
	})
}

Anti-pattern

• assuming table-driven tests cover the strange inputs users, files, or networks will eventually produce

Explanation: This anti-pattern is tempting because hand-picked examples feel complete, but fuzzing is good at finding the cases humans fail to imagine.

Why

• fuzzing complements deterministic tests by exploring the unexpected