Showing posts with label WF4. Show all posts
Showing posts with label WF4. Show all posts

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)
}
else
{
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;
at.Done();
};


wf.GetWorkflowStatusAsync(requestID);
at.Wait();

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.

[TestMethod]
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.

Tuesday, April 27, 2010

Creating a LogError Activity

Surprisingly, in Visual Studio 2010 there is not an Activity in Windows Workflow Foundation (WF) 4.0 that writes an error to the Windows Event Log / Viewer. The good news is that it is very easy to write. Below are the instructions for creating one.

Step 1: Add new Code Activity

Add a new Code Activity called LogError to your Workflow project (This could be any of them, but I recommend putting your Activities in an Activity Library project.).

Step 2: Modify Code Activity to look similar to the following example

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Activities;
using System.Diagnostics;

namespace MyApp.MyActivities
{

public sealed class LogError : CodeActivity
{
// Define an activity input argument of type string
public InArgument<string> PreMessageText { get; set; }
public InArgument<Exception> Exception { get; set; }

protected override void Execute(CodeActivityContext context)
{
Log(PreMessageText.Get(context), Exception.Get(context));
}

public void Log(string preMessageText, Exception ex)
{
string sourceName = "My App";
string logName = "Application"; // i.e. System, Application , or other custom name

if (!EventLog.SourceExists(sourceName))
{
EventLog.CreateEventSource(sourceName, logName);
}

string message = string.Empty;
message += ex.Message + "\r\n";
message += ex.StackTrace;

EventLog.WriteEntry(sourceName, preMessageText + "\r\n" + message, EventLogEntryType.Error);

}
}
}

To use the Activity just compile your project. It will then show up in your Toolbox. You will probably want to drag a TryCatch Activity onto your workflow. Then drag the LogError Activity we created to the Exception section of the TryCatch Activity. Set the Exception property to the argument name in the Exception section.

Misleading error message in Windows Workflow Foundation 4.0

If you are running a Windows Workflow Foundation 4.0 (in Visual Studio 2010) and you are testing it with the WCF Test Client and you get a message similar to the following:

Failed to invoke the service. Possible causes: The service is offline or inaccessible; the client-side configuration does not match the proxy; the existing proxy is invalid. Refer to the stack trace for more detail. You can try to recover by starting a new proxy, restoring to default configuration, or refreshing the service.

The operation could not be performed because WorkflowInstance 'cb123a26-34bd-4ab8-876f-63dee2080b42' has completed.

Server stack trace:

   at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)

   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)

   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)

   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:

   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)

   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

   at IService.GetData(String inParameter1)

   at ServiceClient.GetData(String inParameter1)

The good news is that if you have not messed with bindings, etc, and you made a simple change to the workflow and your service started throwing this exception, it is likely the message is just misleading. I have concluded that you will get this message anytime an exception is thrown during the execution of the workflow. This could be something as simple as a null pointer or much more complex.

The question is how do we figure out what the real exception is. A more important question is how do we catch and log these exception. Without the logging, we won’t know if our users are having issues and how have a clue what the cause is.

One way to address this issue is to Use the TryCatch Activity in Windows Workflow Foundation (WF) Designer in Visual Studio 2010. This works just like a try-catch-finally would work in C#. You can create a custom Code Activity called something like LogError. Click here for details on creating this custom Activity. You can then use it in the catch portion of the TryCatch activity.

You can put the TryCatch Activity at the highest level in your workflow to server as a catch all or you can use it particular points in your workflow. Just like when coding, it is often appropriate to do both.

Now when you try to run test your Workflow you will see your error in the Windows Event Log / Viewer. Since the workflow didn’t return the expected response, you still get this generic / useless error, but at least you know the cause now.

If after all this, there is no exception being thrown then it is likely you are trying to send an message to your workflow that is not valid. By not valid, I mean it could be that the Message you are sending is not to the Current Message. Consider the case where you have 2 ReceiveRequest Activities and they are in a Sequence. If you try to send a Message to the second one before the first one this is not valid. Why? Because they are in a sequence. The first Activity must complete before the second one can be executed. That is the vary nature of a workflow. If you need them to be able to be called regardless of the sequence, then you should probably use the Parallel Activity.

Lastly, if you are executing the Activities in order and still getting the error, make sure you are referencing the same CorrelationHandle and that you have specified a key for it to use as the correlation object. This is essentially a primary key for an instance of the workflow. IN WF3 this was the workflow id. In WF4, you can use a key in your data or you can use a GUID like WF3 did, but in any case, you need to tell all your Receive Activities what you want to use to make the correlation. If you don’t have a correlation handle and key defined then WF4 will have now way of telling what instance of the workflow you are trying to access.