Ive recently put together a WCF step for BizUnit to help us with predominantly with projects using BizTalk 2006 R2. However remember that BizUnit can be used without BizTalk 
Anyway this article will provide some information about the how this is implemented. There is also a link to the sample application at the bottom. In the sample I demonstrate how to call the service in a normal test, then how to use dynamic code and reflection to execute the same test. This dynamic code is basically what is implemented inside the custom BizUnit step. The third test demonstrates how to call BizUnit and allow it to execute your test.
Aim
The aim of the step is to recreate the standard SoapRequestResponseStep that comes out of the box with BizUnit but to do this for WCF services instead. The step will not care about the implementation details of channels and behaviours as it is expected that this will be handled in the configuration files.
Using the BizUnit Step
Using the BizUnit step is supposed to be easy. Im going to assume you have used BizUnit before (if not there are many great articles on the net about this)
The steps to use the BizUnit step are as follows:
1. Ensure that the test can access a proxy to your service
In the sample I have a shared assembly which contains details of the contract. I reference this so that it is copied to the bin directory for my test. Other ways to do this include adding a service reference from your test project.
2. Setup the configuration file with the bindings for your service. This is the same as when you use any WCF service. You need to setup the bindings etc.
3. Create the xml file which will contain your request message. This should deserialize to the type which will represent the input to the service
4. Create your BizUnit test file. The picture below shows the example from the sample below.
The key points in the file are:
- The various type names should equate to the type names for the interface and input to the service.
- The contract name relates to the name given to the endpoint in the config file. If no name is given it will simply load it based on the Interface Type name
- You can add validators to validate and inspect the response from the service in the normal way you would for BizUnit. This means you can do things like a schema validation on the response from your service.
5. Ensure the BizUnit step assembly is copied to the bin directory so the path is correct based on that in the BizUnit test file. I normally do this by simply adding a reference from your Test Project.
6. Write the C# code to call your BizUnit Test.
Hopefully you can see from above there is only a couple of additional things which need to be done in addition to a normal BizUnit test making this fit quite well into the normal BizUnit way of doing things.
Design Decision
One thing people may ask about is why I dont dynamically create the code on the fly for the proxy by looking at the service meta data. This would be a similar approach to the Soap step already in BizUnit. To be honest either would have been fine, but what I tend to find on projects (BizTalk ones anyway) is that I usually have a simple windows forms app which is part of the solution and I use it to demonstrate things. Anyway because of this I will have an assembly containing proxies anyway, so I just reuse this for my tests. The other reason is for the Soap step I think I remember it creating a new proxy assembly for each individual test which can sometimes result in lots of files being created.
Summary
Hopefully you will find this post useful and if there is enough feedback wanting to know more about the internals of the step then I may do an additional post about it. However until then just download the sample below.
Note: When you are going to run the tests, remember to run the host executable so the service is up and running before you run the test.
Disclaimer
I have noticed a few sites that seem to copy the content of blog articles and display them in their own site. It is a bit annoying that they do not clearly reference or acknowledge the author so I have decided to put this note on the bottom of all of my posts from now so it is clear who wrote it.
This article was written by: Michael Stephenson
The source of this article is: http://www.geekswithblogs.net/michaelstephenson