Currently, rv supports inside-out invariant testing, where invariants written in Clarity have direct access to contract state. While this works well, it might be worth exploring outside-in testing.
This approach was used in PoX-4 (stacks-network/stacks-core@57cc223), where rv didn’t yet exist. In @friedger's catamaran-swaps case, Clarity's design (e.g., no native iteration over a map of swaps) makes outside-in testing a suitable approach for verifying balances.
Using the same simnet instance and TypeScript tests, as shown for example in stacks-network/stacks-core@9905e7e, could make this possible.
Supporting both inside-out (tests in Clarity) and outside-in (tests in TypeScript) approaches would make rv more versatile, providing functionality that similar tools (e.g., on Ethereum) often focus on individually:
- Inside-out (e.g., Echidna, dapp.tools, Foundry)
- Outside-in (e.g., Ackee/wake)
This is a placeholder for discussion; more details will follow as we dig into this.
Currently,
rvsupports inside-out invariant testing, where invariants written in Clarity have direct access to contract state. While this works well, it might be worth exploring outside-in testing.This approach was used in PoX-4 (stacks-network/stacks-core@57cc223), where
rvdidn’t yet exist. In @friedger's catamaran-swaps case, Clarity's design (e.g., no native iteration over a map of swaps) makes outside-in testing a suitable approach for verifying balances.Using the same simnet instance and TypeScript tests, as shown for example in stacks-network/stacks-core@9905e7e, could make this possible.
Supporting both inside-out (tests in Clarity) and outside-in (tests in TypeScript) approaches would make
rvmore versatile, providing functionality that similar tools (e.g., on Ethereum) often focus on individually:This is a placeholder for discussion; more details will follow as we dig into this.