-
Notifications
You must be signed in to change notification settings - Fork 25
shrinking optimizations #321
Comments
You mean greater than n?
What do you mean by the monadic case here?
I think these are good ideas! What's your opinion on always keeping the n-th command, so that we don't trigger other bugs while shrinking? |
No smaller. If the command failed on the n-th comman, this means it hasn't failed up to the (n-1)th command, so there is no reason to test these cases.
I mean using Test.QuickCheck.Monadic. The type of monadic |
By always trying to keep n-th command we may miss smaller counter examples which don't contain it. Maybe we can keep shrinked elements which contain the n-th command first on the shrink list. |
I finally managed to make this work (https://github.com/advancedtelematic/quickcheck-state-machine/tree/quick-shrink-monadic) and the results seem good. This is sequential memory referece with a Logic bug (verbose execution):
The execution fails on the 5th command and it quickly shrinks down to this prefix. |
I opened an issue at QuickCheck nick8325/quickcheck#263 |
I'm working on a pr which tries to capture information from the execution of a list of Commands, in order to make shrinking faster. Note that QuickCheck does not support this very well, so it is a bit experimental. It is based on 2 ideas:
Using these ideas the shrink list can be pruned. I have implemented the first part for the non-monadic case and I think the second is also easy to implement. However implementing the monadic case seems tricky.
For some examples which support this idea: Say we have a list of commands [1..20] and execution fails on the 8th command. The shrinker should try to shrink [1..8]. Also
shrinkListS' [1,2,3,4,5,6,7,8] returns
All prefixes, like [1,2,3,4], [1,2,3,4,5,6], [1,2,3,4,5,6,7] can be safely pruned.
Thoughts on this?
The text was updated successfully, but these errors were encountered: