Fuzz testing / property-based testing
Generate many unexpected inputs, check a rule that should always hold, and shrink failures into small reproducible examples.
What it is
Fuzz testing feeds a system many varied inputs and watches for crashes, hangs, or other bad outcomes. Barton Miller coined the name in 1988 after a thunderstorm put line noise on his dial-up session and the garbage characters crashed the program he was using; the class project that followed crashed roughly a third of standard Unix utilities. Property-based testing generates values from a model and checks an invariant for every one, then shrinks a failure toward the smallest counterexample. QuickCheck popularized the property-based style in Haskell; Hypothesis and fast-check bring it to Python and TypeScript.
Reach for these when the input space is too large for hand-picked examples: parsers, serializers, date math, state machines, and security boundaries. Good properties describe relationships, such as decoding an encoded value returns the original, sorting twice changes nothing, or a balance never drops below zero.
Gotcha: generated does not mean thorough. A generator that produces only short ASCII strings never tests Unicode, and a weak property such as 'does not throw' can miss wrong answers. Bias generators toward known boundaries, keep the random seed and shrink path for replay, and retain the smallest failure as a normal regression test.
Ask AI for it
Add property-based tests for <functionName> with fast-check. Define arbitraries that include empty values, Unicode strings, integer boundaries, duplicates, and malformed records; express at least three real invariants with fc.property and run them through fc.assert with numRuns: 1000. Print fast-check's seed and path on failure so the case replays exactly, keep shrinking enabled, and turn every discovered minimum counterexample into a named Vitest regression test.