Unit Testing Duplex WCF Services

One of my readers recently asked me about unit testing WCF services when they have callbacks. Given that I strongly believe that you should attempt to implement your services without referencing WCF at all, but duplex WCF services require you to get the callback instance from OperationContext.Current, how can these two forces be reconciled?

Fortunately, it's really not that hard. All you have to do is to replace the call to OperationContext.GetCallbackChannel<T> with something abstract. On .NET 3.5, the easiest abstraction is Func<TResult>, which has the same signature, but if you are on .NET 3.0, you can always define a similar delegate type of your own.

Let's say that your contracts look like this:

[ServiceContract(CallbackContract = typeof(IStuffCallbackService))]
public interface IStuffService
    void DoStuff(string stuff);

public interface IStuffCallbackService
    void StuffWasDone(string result);

Since it would ruin testability of the IStuffService implementation if it was to use OperationContext.GetCallbackChannel<T> to create a new instance of IStuffCallbackService, it needs an instance of Func<IStuffCallbackService> instead. As I favor Constructor Injection, the complete implementation looks like this:

public class StuffService : IStuffService
    private readonly Func<IStuffCallbackService> createCallbackChannel_;
    public StuffService(Func<IStuffCallbackService> callbackCreator)
        if (callbackCreator == null)
            throw new ArgumentNullException("callbackCreator");
        this.createCallbackChannel_ = callbackCreator;
    #region IStuffService Members
    public void DoStuff(string stuff)
        // Implementation goes here...
        string stuffResult =
            new string(stuff.ToCharArray().Reverse().ToArray());

Such an implementation is imminently testable, as this test demonstrates:

public void DoStuffWillInvokeCallbackService()
    // Fixture setup
    string anonymousStuff = "ploeh";
    string expectedResult = 
        new string(anonymousStuff.ToCharArray().Reverse().ToArray());
    SpyStuffCallbackService spy = new SpyStuffCallbackService();
    StuffService sut = new StuffService(() => spy);
    // Exercise system
    // Verify outcome
        spy.StuffResults.First(), "Callback result");
    // Teardown

The SpyStuffCallbackService class is a simple Test Spy that records all the callbacks in the StuffResults collection.

When you let WCF host the service, you need to tell WCF to use OperationContext.GetCallbackChannel<IStuffCallbackService> as the delegate instance to the StuffService constructor. In my previous post, I demonstrated how to do that (that's what StuffInstancingBehavior.GetInstance does).

Update (2008-07-12): I've just posted an overvview of the solution, as well as all the sample code.

Comments (5)

  1. ploeh blog says:

    In my previous post , I explained how to unit test a WCF service with callbacks. Since the scenario involves

  2. ploeh blog says:

    In the last couple of posts, I’ve demonstrated how to isolate implementation from WCF contract definition

  3. Alexander Loginov says:

    Hi, Mark. Your methodology of unit testing of Duplex WCF Services is very interesting for me.

    I understand that is very GLOBAL question, but how can I use it at WCF service with many subscribers (callback sends not only to one client, but to all subscribers)?

  4. ploeh says:

    Hi Alexander

    Thank you for your question. If you take a look at e.g. http://idunno.org/archive/2008/05/29/wcf-callbacks-a-beginners-guide.aspx for an approach to web service eventing, you’ll see that it’s very similar to my examples. The major difference is that instead of immediately invoking the callback, it’s being saved for later.

    You can basically proceed with unit testing as I describe above. When first you’ve managed to pull WCF away from the implementation, unit testing can proceed like unit testing of any other code. When dealing with collections of multiple objects, I typically find that a good equivalence count is the number three. In your case, it would translate to that if you can unit test successfully with three subscribers, it’s probably also going to work with any larger number as well (functionally, that is – keep in mind that a unit test is never a performance or stress test).


Skip to main content