Fix receiveWait test
See https://github.com/simonmar/distributed-process/commit/ad2d328d33bf92102f8d694886f2f44a12c68e3a.
Maybe I'm missing something, but I don't get what exceptions you're talking about in https://github.com/simonmar/distributed-process/commit/ad2d328d33bf92102f8d694886f2f44a12c68e3a Simon. Are you talking about the kill p "BANG" calls? Because that's an asynchronous primitive and you'll only see the results of it if you're monitoring the target process won't you?
If that is what we're looking for here, then we do similar stuff in the tests for distributed-process-platform's Timer module here and the Async Process API here. Perhaps we can borrow some of those ideas? e.g.,
testAsyncCancel :: TestResult (AsyncResult ()) -> Process ()
testAsyncCancel result = do
hAsync <- async $ runTestProcess $ say "running" >> return ()
sleep $ milliseconds 100
p <- poll hAsync
case p of
AsyncPending -> cancel hAsync >> wait hAsync >>= stash result
_ -> say (show p) >> stash result p
testCancelTimer :: TestResult Bool -> Process ()
testCancelTimer result = do
let delay = milliseconds 50
pid <- periodically delay noop
ref <- monitor pid
sleep $ seconds 1
cancelTimer pid
_ <- receiveWait [
match (\(ProcessMonitorNotification ref' pid' _) ->
stash result $ ref == ref' && pid == pid') ]
return ()
testRunAfter :: TestResult Bool -> Process ()
testRunAfter result = do
let delay = seconds 2
parentPid <- getSelfPid
_ <- spawnLocal $ do
_ <- runAfter delay $ send parentPid Ping
return ()
msg <- expectTimeout (intervalToMs delay * 4)
case msg of
Just Ping -> stash result True
Nothing -> stash result False
return ()
The problem I'm referring to is that if the test fails, test-framework still reports success. You can see what happens by modifying the test so it fails. This seems to be because the exception thrown by @?= is not propagated (it is not even reported to stdout). I haven't investigated why that is yet.
Hmn, that's annoying. Don't you want to stash the result somehow and/or split the test cases up into separate functions anyway - which makes using assertBool or some such easier - otherwise if you throw an exception and it does get propagated, won't that prevent the subsequent test cases from getting run?
Yes, the tests should be split up, that's a separate issue though.