Parameterized, Property-Based, and Fuzz Testing Capabilities

[moodmosaic]

Traditional example-based testing falls short in covering the wide array of input combinations and edge cases:

• each test executes once, with concrete input values. That is, unit test functions are public and without parameters.

---

As our ecosystem grow more sophisticated, the testing methods must evolve to identify vulnerabilities and ensure contract robustness:

• at the very least, each test must be able to run multiple times with randomly generated concrete values (smaller values, à la property-based testing).

(From there, via Clarinet config/flag, you can tell to the underling data generator to be biased, and then you'll have turned your property-based tests to look more like fuzz tests—one of the reasons why foundry uses that terminology as well. 🔢)

To summarize:

type	prefix	arguments	semantics
concrete	test	no	single execution with concrete values (you are here)
property	test	yes	multiple executions with randomly generated concrete values (smaller values)
fuzz	test	yes	multiple executions with randomly generated concrete values (biased)

---

See also:

• https://github.com/dapphub/dapptools/tree/master/src/dapp#property-based-testing
• https://fv.ethereum.org/2020/12/11/symbolic-execution-with-ds-test/#using-ds-test
• https://github.com/crytic/echidna?tab=readme-ov-file#writing-invariants
• https://book.getfoundry.sh/forge/advanced-testing
• https://github.com/citycoins/protocol/issues/3#issuecomment-1264098480
• https://github.com/hirosystems/clarinet/issues/398
• https://github.com/stacks-network/sbtc/pull/352
• https://github.com/PromptECO/clarity-sequence/issues/4#issuecomment-1329303698

[moodmosaic]

This can be added to the list: https://x.com/PatrickAlphaC/status/1624137622510571522.