With the introduction of time locks (#107) we have implementations of either arbitrary::Arbitrary or proptest::Arbitrary for several key structs related to transaction validity. Previously, we had pseudorandom mock object generators. In fact, there still are some, in particular in connection to removal records integrity. These should be phased out --
[ ] phase out pseudorandom test case generators
-- and replaced with appropriate implementations of Arbitrary. Using the test frameworks proptest, arbitrary, and test_strategy is preferable because:
✓(like pseudorandom generators) they can be fully derandomized
✓failing test cases are automatically recorded and saved to disk
✓failing test cases are automatically reduced to still failing test cases with minimal complexity
✓writing constraints for arbitrary objects is simple and straightforwards, and results in concise property tests.
With the introduction of time locks (#107) we have implementations of either
arbitrary::Arbitraryorproptest::Arbitraryfor several key structs related to transaction validity. Previously, we had pseudorandom mock object generators. In fact, there still are some, in particular in connection to removal records integrity. These should be phased out ---- and replaced with appropriate implementations of
Arbitrary. Using the test frameworksproptest,arbitrary, andtest_strategyis preferable because:arbitraryobjects is simple and straightforwards, and results in concise property tests.