distributed-process icon indicating copy to clipboard operation
distributed-process copied to clipboard

Fix receiveWait test

Open edsko opened this issue 13 years ago • 4 comments

See https://github.com/simonmar/distributed-process/commit/ad2d328d33bf92102f8d694886f2f44a12c68e3a.

edsko avatar Dec 14 '12 12:12 edsko

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 ()

hyperthunk avatar Dec 17 '12 01:12 hyperthunk

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.

simonmar avatar Dec 17 '12 08:12 simonmar

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?

hyperthunk avatar Dec 17 '12 11:12 hyperthunk

Yes, the tests should be split up, that's a separate issue though.

simonmar avatar Dec 18 '12 10:12 simonmar