Monday, May 17, 2010

Unit Testing Asynchronous calls in Visual Studio 2010

I am simply amazed how much effort I had to go through to figure out how to test asynchronous calls in Visual Studio 2010 (VS2010). In the end, I was able to figure it out with the help of some blogs that I read.

VS2010 ships with integrated Unit Testing which I would like to take advantage of. I am writing a Silverlight application that calls a Windows Workflow Foundation service that I implemented using the WCF Workflow Service Application. I really like it, but I want to be able to unit test the workflow service.

The only way I found to test a WCF Workflow Service Application that I could find was to add a Service Reference to my Unit Test project. This is good for me because that is how Silverlight will call it. The problem is that the WCF Workflow Service Application can’t be called synchronously. So, we have to call it Asynchronously. The problem is that the Unit Test framework used in VS2010 does not support Asynchronous calls in  a Unit Test. Well, it runs, but doesn’t wait for the response to the Async call, so the test is pretty worthless.

Now that you know what I am trying to do, here is what I found as solutions.

Option 1: Simulate Synchronous call using an Asynchronous call

Here is a class I created to simplify the process of make an asynchronous call appear to be synchronous.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace MyApp.Tests
public class AsyncTest

// max number of milliseconds to wait for an asynchronous call
int timeout = -1;

public AsyncTest()
// if debugging, make it a much larger like infinity
if (System.Diagnostics.Debugger.IsAttached)
timeout = -1; // infinity (wait for ever)
timeout = 20 * 1000; // 10 seconds

public AsyncTest(int timeout)
this.timeout = timeout;

// we'll use this to make the current thread wait until our asynchrous call finishes
ManualResetEvent block = new ManualResetEvent(false);

// we'll use this to flag if/when our async call finishes
bool isAsyncDone = false;

public void Done()
isAsyncDone = true; // flag that we are done (do NOT do this after calling block.Set() this will cause race conditions!!!!)
block.Set(); // tell the calling / this thread that it can continue now.

public void Wait()
block.WaitOne(timeout, false); // wait until block.Set() is called or the timeout expires (which ever comes).
Assert.IsTrue(isAsyncDone, "Test took too long"); // if it took too long then report it to the test framework.
block.Reset(); // set the event to non-signaled before making the next asynchronous call.

Here is an example of how you would use it to create a method that acts like a synchronous method, but calls an asynchronous WCF Service.

public GetWorkflowStatusCompletedEventArgs GetWorkflowStatus(long requestID)
AsyncTest at = new AsyncTest();

GetWorkflowStatusCompletedEventArgs returnedArgs = null;

// setup our service reference and callback for when it is done
ServiceClient wf = new ServiceClient();
wf.GetWorkflowStatusCompleted += delegate(object sender, GetWorkflowStatusCompletedEventArgs e)
returnedArgs = e;


return returnedArgs;

I created one of these methods for each of the asynchronous methods I wanted to test. In fact I created a helper class to hold them. Now, in my class that has all my tests in it, I just call the methods on this helper class which are synchronous. Now the test run properly.

For completeness, here is what the unit test (testmethod) would look like.

public void TestCanGetWorkflowStatusTwiceInARow()
var status = Helper.GetWorkflowStatus(1234);
Assert.AreEqual<long>(status.RequestID, requestData.RequestID, "The wrong request id was returned.");
Assert.IsTrue(status.RequestID > 0);
Now I can write a unit test just as easily as I do any other unit test. The synchronous / asynchronous issue is encapsulated in a helper class. I like it. Not much extra work either. Especially since each helper method I write is almost identical. It could be generated if desired (using CodeSmith, etc).
I wish I could take credit for all this, but I can’t. The solution / implementation is completely mine, but the underlying technique is borrowed. For more info on those links, see here:

Option 2: Use the Silverlight Unit Test Application

I think this method is a reasonable approach, but for testing a WCF Service, it seems a bit unnatural to me. I like Option 1 better because I want my test results to be managed in VS2010. If nothing else other than no browser opens and also that you can block check-in of code if tests fail. The integrated Unit testing just seems a bit more integrated with VS2010.
I do think the Silverlight Unit Test Application is a great testing technology. However, I think it is best and most natural for testing Silverlight applications, not the web services they call.
There are lots of good blogs on the subject, so I won’t repeat it here. Here are some of the blogs that I found particularly useful when I went down this road.

1 comment:

Unknown said...

This is beautiful. Works like a dream! Thanks!