Property-based testing
P30.property-based.01 · Audience: guest, it-ml, language-pro · Prerequisites: Fixtures & parametrisation
Example tests check the inputs you thought of. The bugs live in the ones you
did not - the empty list, the run of ten, the string with a digit already in
it. Property-based testing flips the burden: you state an invariant that
should hold for every input, a generator invents hundreds of inputs, and when
one breaks the property it shrinks that input to the smallest version that
still fails. hypothesis is the production tool; this module builds its beating
heart - generate, check, shrink - in a few lines each.
ⓘ Concept: An invariant that holds for every input
decode(encode(s)) == s, sorted(xs) is ordered and a permutation of xs, reverse(reverse(xs)) == xs. You assert the rule once; the framework supplies the inputs. It is parametrisation with the table generated for you.Why it matters — Parametrisation was you listing cases; a property is the machine listing them - it reaches the empty, the huge, and the weird inputs your imagination skips, which is exactly where bugs hide.
Ask the mentor about this module
Ask a question about this content. The mentor explains and grounds its answer in what you are studying; asking is recorded as a learning signal, not a grade.
🎓 Practice ladder
4 graded rungs · ~45 minYour turn: write for_all to find a counterexample, then
shrink to minimise it, argue property vs example, and close with
the interview on deriving properties for merge().
Rung 1 - for_all: check a property over many inputs
Loading exercise…
Rung 2 - shrink a counterexample to its minimum
Loading exercise…
Rung 3 - property vs example: what does each catch? (free-form)
Loading exercise…
Interview rung - derive the properties for merge() (free-form)
Loading exercise…
Property-based testing is not a replacement for examples - it is a searchlight
for the inputs you would never think to write down. Build the generator and the
shrinker once, and @given stops being magic.
Where next?
Go up a level