In this track: Build, test and reason
Fuzz testing explained
Generate many inputs for a stated property.
A test can try a broad range of ruler measurements instead of only one example.
1 ETH = 1000000000 Gwei = 1000000000000000000 Wei.
Write the property first
For a unit conversion, parsing then formatting valid exact input should preserve its value under the chosen normalization rules. State which inputs are in scope.
Generate useful ranges
Include zero, boundary values and large integers rather than only ordinary random-looking numbers. Constrain inputs only for reasons justified by the property.
Keep counterexamples
When a generated input fails, record the seed and minimal reproducing value. Reproducibility turns a one-off failure into an actionable test.
Avoid overclaiming coverage
Many generated tests can miss a rare path or a bad assumption in the property itself. Fuzzing adds evidence rather than a proof of universal safety.
Define the test
generate valid raw amount n
format n → decimal text
parse decimal text → m
assert m == nTest plans are framework-neutral unless labeled as complete Solidity or JavaScript. Use a local test environment and no real funds.
What should a useful fuzz test assert?
Generation needs an expected relationship or invariant.
Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.