Back to Questions
2.8k
views2
comments
More questions on F# events (this might be kinda long)
f#testingworkflowsasyncasynchronous

Ok, hopefully I can explain this well enough that some of the more experienced F# guys will not only understand what I'm trying to do, but also possibly offer up suggestions about how to make this work in F#.

Lately I've been building lots of fairly complex asynchronous event driven systems, both client-side and server-side. I've done all this in C# at work, and one thing that is really kinda painful is testing these applications using NUnit or MSTest. However, I did manage to come up with a pretty cool mechanism for testing this stuff in C# but its kinda hard to read due to the inversion of control required in order for the test program to wait for an async event to occur and then perform the assertion or fail if it doesn't occur within the specified time-span.

In C# the way I handled this was by building a class I called WaiterWorkItem which would be given an event to subscribe to in its constructor. Inside the WaiterWorkItem would also be a flag which would be set to true once the event was raised. WaiterWorkItem.Start would be given a lambda that would start the work that would eventually trigger the event, then it would be enqueued to the TestQueue (in MSTest) and exec the lambda. When the WaiterWorkItem was popped off the TestQueue it would check the event triggered flag and if true would exit, otherwise it would requeue the WaiterWorkItem if the specified wait time had not yet occurred, or it would Assert.Fail() if the timeout had expired.

F#'s async workflows and event handling via Observable look really really cool. And on the surface it seems like they should allow me to do something similar to what I described of C# and WaiterWorkItem but without having the code inversed. The reason I'm making this long post is because I just haven't been able to figure out how to make this happen in F# short or recoding WaiterWorkItem and suffering the same hard to read test cases.

In F# I have a Class defined with a MailboxProcessor that does async work and fires events at various times. My test case has an async workflow that looks like this:

1
2
3
4
5
6
7
8
9
10

[<Test>]
member this.``Test Async``
   ...
   let doWork = async {
      Async.Start(foo.Execute)
      return! Async.AwaitEvent(FooCompletedEvent)
      }

   let result = Async.RunSynchronously(doWork, 10000)
   result |> should equal someValue

The problem with this is that it only works sometimes. I believe that what is going wrong is foo.Execute can already have fired the event before Async.AwaitEvent is called, which means it isn't fired again and RunSynchronously timesout. So far I haven't figured out a way to make this work with the Async module. Continuations look like they're pretty close, but I havent figured that out yet.

Hopefully this is clear enough to understand. Its really late right now, and once again the example code above is from memory at 1:30am so I'm sure it isn't perfect.

Derek

.

This comes up a lot, so someone (Tomas) invented Event.guard:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

    module Event = 
        let guard f (e:IEvent<'Del, 'Args>) =  
            let e = Event.map id e 
            { new obj() with
                  member x.ToString() = ""
              interface IEvent<'Args>  
              interface IDelegateEvent<Handler<'Args>> with 
                  member x.AddHandler(d) = e.AddHandler(d); f()
                  member x.RemoveHandler(d) = e.RemoveHandler(d) 
              interface System.IObservable<'Args> with 
                  member x.Subscribe(observer) =  
                      let rm = e.Subscribe(observer) 
                      f() 
                      rm }

so that rather than

1
2

   somethingThatStartsAnAsyncThatEventuallyFires()
   Async.AwaitEvent(TheEvent)

which is subject to the race you've seen, you can do

1

   Async.AwaitEvent( Event.guard (fun () -> somethingThat...() ) TheEvent )

which subscribes first, then runs the lambda, and then returns the event you can await. That is, Event.guard takes a lambda and an event, and returns that same event except it will run the lambda after subscribing so that you never 'miss' the event if the lambda may provoke it.

By on 11/25/2010 10:14 AM ()

Hi,

don't know if this is really the issue but it might be.

I suggest stop using the events but working with System.Threading.ManualResetEvent to check states. Or - and that might be even better - use System.Threading.Task to do this stuff (in C# or F# - no matter)

By on 11/25/2010 3:58 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper