go-kata/06-testing-quality/15-testing-parallel-fuzz-harness/README.md

Kata 15: The Go Test Harness (Subtests, Parallel, Fuzz)

Target Idioms: Table-Driven Tests, t.Run, t.Parallel, Fuzzing (go test -fuzz)
Difficulty: 🟡 Intermediate

🧠 The "Why"

Developers often write:

• one-off tests with repetition,
• unsafe parallel subtests (loop variable capture),
• no fuzz testing for parsers/sanitizers.

Idiomatic Go testing is:

• table-driven,
• readable failures,
• parallel where safe,
• fuzzed for edge cases.

🎯 The Scenario

You’re implementing a sanitizer:

• func NormalizeHeaderKey(s string) (string, error) Rules:
• only ASCII letters/digits/hyphen allowed
• normalize to canonical header form (e.g., content-type -> Content-Type)
• reject invalid input

🛠 The Challenge

Write:

1. The implementation, and
2. A test suite that proves it’s solid.

1. Functional Requirements

• Canonicalize valid inputs.
• Reject invalid characters.
• Stable behavior (same input => same output).

2. The "Idiomatic" Constraints (Pass/Fail Criteria)

• Tests must be table-driven with t.Run.
• Use parallel subtests correctly (no loop var capture bugs).
• Include a fuzz test that:
  • never panics,
  • never returns a string containing invalid characters,
  • roundtrips canonical form (calling Normalize twice is idempotent).

🧪 Self-Correction (Test Yourself)

• If parallel subtests flake: you likely captured the loop variable.
• If fuzzing finds panics: you missed an edge case.

📚 Resources

• https://go.dev/blog/subtests
• https://go.dev/wiki/TableDrivenTests
• https://go.dev/doc/security/fuzz/
• https://go.dev/doc/tutorial/fuzz