Testing asynchronous APIs about quickcheck-state-machine HOT 3 OPEN

One way to hide the history channel from the user, could be to have the user provide a function that triggers invocation events:

triggers :: action Concrete resp -> Maybe (exists resp'. action Concrete resp')

And another function that creates response events:

environmentResponses :: Producer IO (Constructor, Dynamic)

In the above example the implementations of these would be something like:

triggers (Add i) = Just Sum
triggers Sum    = Nothing

environmentResponses = do
  msg <- readMessageFromBus
  case msg of
    'S' : 'u' : 'm' : ' ' : n : [] -> yield (Constructor "Sum", toDyn (read n :: Int))
    _ -> environmentResponses

from quickcheck-state-machine.

I still think this is an interesting topic, but I'm not working on this actively.

If I would revisit it, then I would try to combine what I've learned from https://github.com/advancedtelematic/quickcheck-state-machine-distributed and the literature on behavioral programming.

from quickcheck-state-machine.

https://web.archive.org/web/20160405163934/people.brunel.ac.uk/~csstrmh/research/asynchronous_testing.html

from quickcheck-state-machine.