Abstract state machine testing

[jacobstanley]

A colleague pointed me to the release of the very cool quickcheck-state-machine so I decided I'd better stop sitting on this and actually publish it!

It's still a little raw in the sense that you need to write a few boilerplate instances for your commands, and there isn't any parallel testing yet. I think parallel testing should fit in to the design without any issues however.

I rejigged the Hedgehog.Gen and Hedgehog.Range modules so they're just re-exporting from internals in order to add Gen.actions as a thing. (sorry @charleso :# ! it's all about syntax)

Here's some sample output from the two examples I've knocked together so far.

Process Registry

Mutable References

/cc @moodmosaic @thumphries @charleso

[charleso]

I have mixed feelings about this. Alternatively would it be possible to provide extra constructor functions with defaults? Would that be better/worse?

[jacobstanley]

It's not really possible to do the defaults thing because of the existentials.

I convinced myself that this is the least bad solution. I liked it because it has the benefit of being able to abstract over the functions that implement the model itself. For example if you have pre- & post-conditions which are shared between a number of commands then you can pull them out and just append it to your list.

Is it just the name which gives a bad feel? I took the callback terminology from the Erlang QuickCheck, but happy to change to something else.

[charleso]

As discussed, was just curious. As long as it's not just for convenience but because it's a better API, which is sounds like it is. Just ignore me. :)

[jacobstanley]

I guess we'll find out! really hard to say without using it in anger, we can always change it