Share via

An Overview of Unit Testing Duplex WCF Services and Clients

  • Article

In the last couple of posts, I've demonstrated how to isolate implementation from WCF contract definition and behavior in a duplex communication scenario. These posts have been rather detailed, so it occurred to me that you might benefit from an overview.

The main goal was to ensure testability of implementations of both service and client. While the contracts reference WCF (System.ServiceModel), the implementations themselves only reference the contracts, and not WCF.

DependencyGraph

This diagram illustrates dependencies between the various libraries. The left side contains server-side components, while the right side contains client-side components. The only shared components are WCF and the Contract library.

Note that neither StuffServer nor StuffAgent has any dependency on System.ServiceModel, although they have a dependency on Contract. The same is true for both unit test projects.

The top boxes on both sides (MyServer and MyClient) are hypothetical top-level executables such as I've discussed before, although never shown any code from. These Humble Executables tie everything together by referencing all relevant libraries, but if you prefer, you can just as well use a configurable Dependency Injection container - Oran Dennison explains how to do this on Spring.NET, while Ayende has a Windsor ServiceHostFactory.

Here are the main posts on the subject:

If you would like to take a closer look at my sample code, I've attached it to this post. As usual, the standard disclaimers apply.

DuplexServiceUnitTesting.zip

Comments

  • Anonymous
    July 11, 2008
    PingBack from http://blogs.msdn.com/ploeh/archive/2008/06/28/unit-testing-duplex-wcf-services.aspx

  • Anonymous
    July 11, 2008
    In my previous post , I explained how to implement a WCF service without referencing WCF. In simple cases,

  • Anonymous
    February 16, 2009
    Hi Thanks for this sample. But i've still one question: I do need the OperationContext.Current, but it is always null. Do i have to initialize it somwhere? cheers manuel

  • Anonymous
    February 16, 2009
    Hi Manuel Thank you for your question. Please note that ploeh blog has moved. You really should be unit testing your services, but as you state, that will cause OperationContext.Current to be always null. Which is why you should avoid using OperationContext.Current in your service implementation. If you already have a service implementation with calls to OperationContext.Current or other tightly coupled code liberally sprinkled all over, you will need to integration test your service.