WF4: How to Unit Test a Workflow that calls a WCF Service

Artigo
01/20/2011

“The important point is that our test can’t control what that dependency returns to our code under test or how it behaves (if we wanted to simulate an exception, for example). That’s when we use stubs.” – The Art of Unit Testing - Roy Osherove,

Yesterday morning I received an email from Ryo in Belgium who asked for help in unit testing a workflow. Ryo had read my previous posts on Microsoft.Activities.UnitTesting.XamlInjector and wanted to use it to test his workflow but was having trouble. I gave him a quick suggestion and a little later he wrote back still having trouble and sent me some test code so I decided to fix it for him. Several hours later I had a new update to Microsoft.Activities.UnitTesting which I will share with you now.

Note: This video uses smooth streaming. If it is hard to read the screen, just go full screen and wait about 30 seconds for the smooth streaming to kick in

Scenario: Unit Testing a Workflow that calls a WCF service

Given

A console application with a self-hosted WCF Calculator Service
A WF4 Workflow that
- Accepts arguments to pass to the WCF service
- and uses Send and ReceiveReply activities to invoke the WCF Service
- and returns the result to the caller
A Unit Test that runs the workflow and verifies that the workflow returns correct output when provided correct input

When

The unit test is run
and the console application is not running

Then

The unit test should complete successfully

What Are We Testing Exactly?

In this scenario there are two components.

The WCF Calculator Service
The Workflow which has a dependency on the service

As Roy Osherove said in the quote at the top of this post we want to avoid external dependencies in our unit testing. We should test both components in isolation such that one does not depend on the other at test time.

Testing Workflows With Stubs

Here is the unit test that Ryo provided

 //Not good, need the Wcf service running
 [TestMethod]
 public void TestMethod3()
 {
     IDictionary<string, object> result = WorkflowInvoker.Invoke(new Workflow1()
     {
         x = 3,
         y = 5
     });
  
     Assert.AreEqual(8, result["result"]);
     Assert.AreNotEqual(10, result["result"]);            
 }

To eliminate the WCF Service from our unit test we will use stubs. In our workflow there are two activities that need to be replaced with a stub.

Activity	Behavior	Stub Behavior
Send	Sends a message to the service. If the service cannot be reached the activity will throw an exception	Do nothing, assume that the message will be sent succesfully.
ReceiveReply	Receives a response from the service and stores the value in variables or arguments in the workflow	Store an expected response in the variables or arguments of the workflow

When you create a stub you create an object that has the same method signature. Activities in Workflow also have a signature. The way to see it clearly is to look at the XAML. Here is the Send activity.

 <p1:Send x:Name="__ReferenceID0" OperationName="Sum" ServiceContractName="p:ICalc">
   <p1:Send.CorrelationInitializers>
     <p1:RequestReplyCorrelationInitializer CorrelationHandle="[__handle1]" />
   </p1:Send.CorrelationInitializers>
   <p1:Send.Endpoint>
     <p1:Endpoint AddressUri="net.tcp://localhost:8009/CalculatorService/Calculator">
       <p1:Endpoint.Binding>
         <p1:NetTcpBinding Name="netTcpBinding" />
       </p1:Endpoint.Binding>
     </p1:Endpoint>
   </p1:Send.Endpoint>
   <p1:SendParametersContent>
     <InArgument x:TypeArguments="x:Int32" x:Key="a">[x]</InArgument>
     <InArgument x:TypeArguments="x:Int32" x:Key="b">[y]</InArgument>
   </p1:SendParametersContent>
 </p1:Send>

You can see that it has a number of properties that need to be duplicated in the stub send activity. The goal is to rewrite the XAML so that all we do is replace Send with SendStub. Everything else should remain the same. Sounds simple right? I thought so too until I tried to create one. The good news is that after several hours, I came up with a set of messaging stub activities that are now in the latest release of Microsoft.Activities.UnitTesting so you won’t have to build them. Using these stubs I was able to create a unit test that implemented our scenario perfectly.

 using Microsoft.Activities.UnitTesting.Stubs;
  
 [TestClass]
 public class UnitTest1
 {
     /// <summary>
     /// Invokes the Workflow but does not actually send or receive messages. 
     /// </summary>
     /// <remarks>
     /// This type of test can validate the logic of the workflow without sending/receiving messages.
     /// It does this by replacing the messaging activities with stubs as it creates a 
     /// test version of the XAML and runs it.
     /// Note: You must deploy the .xaml file for this test to work
     /// </remarks>
     [TestMethod]
     [DeploymentItem(@"MyWorkflow\Workflow1.xaml")]
     public void TestMethod1()
     {
         const int expectedResult = 12;
  
         // The XamlInjector will create our injected xaml file Workflow1.Test.xaml 
         // in the test output directory
         var xamlInjector = new XamlInjector("Workflow1.xaml");
  
         // If you need to simulate sending the actual values you can do this
         // Create send parameters using the names on the send activity
         var sendParameters = new Dictionary<string, object>() { { "a", 5 }, { "b", 7 } };
         var sendImplementation = new SendParametersStubImplementation(sendParameters);
  
         // Replace the sender with the SendStub
         xamlInjector.ReplaceAll(typeof(Send), typeof(SendStub));
  
         // Setup the response parameters using the name on the ReceiveReply activity
         var receiveParameters = new Dictionary<string, object>() { { "SumResult", expectedResult } };
         var receiveImplementation = new ReceiveParametersStubImplementation(receiveParameters);
  
         // You must replace the receiver or the workflow will wait for a response
         xamlInjector.ReplaceAll(typeof(ReceiveReply), typeof(ReceiveReplyStub));
  
         // Have to create an invoker so we can add extensions
         WorkflowInvokerTest host = new WorkflowInvokerTest(xamlInjector.GetActivity());
  
         // Stubs look for extensions to provide implementation
         host.Invoker.Extensions.Add(sendImplementation);
         host.Invoker.Extensions.Add(receiveImplementation);
  
         // Stubs eliminate bookmarks so WorkflowInvoker can test the activity
         // Messaging activities cannot be tested with invoker otherwise.
         var result = host.TestActivity();
  
         // This assert is ok
         Assert.AreEqual(expectedResult, result["result"]);
  
         // This is better - it provides better error messages and checks
         host.AssertOutArgument.AreEqual("result", expectedResult);
  
         // To see what is going on, trace the tracking info and check the test results
         host.Tracking.Trace();
     }

Happy Coding!

Ron Jacobs

https://blogs.msdn.com/rjacobs
Twitter: @ronljacobs

Comments

Anonymous
February 01, 2011
Good to have Stub Send Recv implementations. Is there any way to test the Receive-SendReply, having CorrelateOn property set, using Stubs.
Anonymous
February 01, 2011
I haven't tried this but the correlation properties are there. The stubs won't actually try to do anything with them so the idea is that the workflow wouldn't actually load anything.
Anonymous
February 02, 2011
Thanks Ron for your response. I will try it.

Compartilhar via