stacks-network / stacks-test-tools Goto Github PK

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:

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
• citycoins/protocol#3 (comment)
• hirosystems/clarinet#398
• stacks-network/sbtc#352
• PromptECO/clarity-sequence#4 (comment)

          Ok indeed it looks like neither of us can publish. Could be nice to have it in the CI

Originally posted by @hugocaillard in #4 (comment)