An Overview of Unit Testing Duplex WCF Services and Clients

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.


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.

Comments (4)

  1. ploeh blog says:

    In my previous post , I explained how to implement a WCF service without referencing WCF. In simple cases,

  2. Manuel says:


    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?



  3. ploeh says:

    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.