“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
- 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
- The unit test is run
- and the console application is not running
- 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
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.
|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.
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.