A few years ago, when ASP.NET web services were the only (or at least most common) implementation of web services on the Microsoft platform, you couldn't really unit test services. Obviously, since you had programmatic access (via a proxy class) to the service, you could write tests against the service using unit testing tools, but in my terminology, these tests are integration tests, not unit tests.

This lead to the guiding principle that a service should just be a remote façade for a service library; that service library could then be subjected to unit testing, and the service itself would just delegate all messages to the library (and thus contain so little code that it didn't require testing in itself).

With WCF, this is no longer the case, since WCF services are just libraries. This means that you can just add a reference to your service from a test project, and start writing tests against the library like this:

public void DoStuffInProcess()
    MyService ms = new MyService();
    string result = ms.DoStuff("Ploeh");
    Assert.AreEqual<string>("Ploeh", result);

However, to be able to do this, you must ensure that the service library doesn't use any WCF-specific code. As soon as you begin to use OperationContext.Current in your service, your unit tests are very likely to fail, since this static property will be null when not hosted by WCF.

Although this may feel like too much of a constraint, this is often a beneficial approach, since it helps ensure separation of concerns. Service operations should implement business logic, not transport logic or other, similar kinds of unrelated activity.

While that may be true, you will often still need to know something about the context of the operation, such as the identity of the caller. In many cases, such requirements can still be addressed while maintaining separation of concerns, since WCF allows you to configure message interceptors, authorization managers, etc.

Even if you are able obtain perfect separation of concerns, you may still want to test your authorization managers or other extensions, and that will often require hosting by WCF. In such cases, integration testing is the proper approach, but that doesn't mean that you shouldn't unit test as far as you can get.

In future articles, I will write about integration testing of WCF services. Update: My first WCF integration testing post is now online.