property-based-testing

Use the @given decorator with strategies like st.integers() or st.lists() to generate inputs, then assert an algebraic property such as a roundtrip or invariant. Put constraints in the strategy itself rather than assume(), and pin known edge cases with @example.

The strongest property is the roundtrip: decode(encode(x)) == x. If no decoder exists, fall back to invariants or determinism checks, since asserting only 'no crash' rarely justifies adding a PBT dependency.

Match the project's language and existing choice: Hypothesis for Python, fast-check for TypeScript/JavaScript, proptest for Rust, rapid for Go, and jqwik for Java. Introducing a second PBT library into a codebase that already has one is not worth it.

The two common causes are tautology, where the assertion restates the implementation, and vacuity, where assume() filters out nearly every generated input. Push constraints into the strategy so the generator produces valid inputs directly.

Write echidna_ functions that are view/pure, take no arguments, and return a bool that must never become false, such as totalSupply matching a tracked sum. Use assertion mode with assert() inside callable functions for operation-specific properties.

Avoid it for code with no algebraic shape where the only assertable property is 'no crash', and for coverage-guided binary fuzzing, mutation testing, static analysis, or end-to-end UI tests, which need different tools.