property-based-testing

Use the @given decorator with strategies from hypothesis.strategies to generate inputs, then assert algebraic properties like roundtrip or idempotence. Build constraints into the strategy itself rather than filtering with assume(), and add @example decorators for edge cases.

Serialization pairs should be tested with a roundtrip property: decode(encode(x)) == x. Also test that encoding is deterministic and produces the expected output type, and that decoding invalid bytes raises the documented exception.

Use Hypothesis for Python, fast-check for JavaScript/TypeScript, proptest for Rust, rapid for Go, jqwik for Java, and ScalaCheck for Scala. For Solidity smart contracts, use Echidna or Medusa fuzzers to test state invariants.

Failures may be genuine bugs, test bugs, or ambiguous specifications. Reproduce with the shrunk minimal example, verify the property against docstrings and type annotations, and check whether the failing input is within the documented domain before reporting a bug.

Avoid property-based testing for simple CRUD operations without transformation logic, UI code, integration tests requiring external services, and throwaway scripts. It works best for unit-level pure functions with complex input domains.

Use Echidna or Medusa fuzzers to test state invariants in EVM contracts. Write functions prefixed with echidna_ that return a boolean invariant, such as verifying balances remain non-negative, and the fuzzer generates transaction sequences to violate them.