Middle · Testing and performance
Fuzzing parsers with useful properties
What property would you fuzz for a custom codec?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
A round-trip property checks Decode(Encode(x)) against a canonical form of x; decoder-only fuzzing should also assert bounded handling and no unexpected panic for arbitrary bytes. Seed known boundary and regression cases.
Define invalid-input behavior and resource limits first. Fuzzing a decoder that allocates directly from untrusted lengths can exhaust resources before finding useful bugs. Do not compare representations whose order is intentionally unspecified.
Keep minimized failures as regression seeds. Fuzzing explores inputs, but cannot prove protocol security or cover every concurrency schedule; complement it with examples, limits and targeted race/fault tests.
Common trap
“Does not panic” is weaker than correct parsing and does not detect silent corruption.
Try it
An encoder sorts map keys before serialization. What should the round-trip comparison assert?
Worked solution
Assert semantic key/value equality after decode, not the original map iteration order. Separately test deterministic encoded bytes and reject length prefixes exceeding the configured bound.
Change the constraint
How would you fuzz a streaming decoder with arbitrary chunk boundaries?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.