You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
With the introduction of time locks (#107) we have implementations of either
arbitrary::Arbitrary
orproptest::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 ---- and replaced with appropriate implementations of
Arbitrary
. Using the test frameworksproptest
,arbitrary
, andtest_strategy
is preferable because:arbitrary
objects is simple and straightforwards, and results in concise property tests.The text was updated successfully, but these errors were encountered: