Unit Testing WCF Services

A colleague of mine recently wrote about seperation of concerns in relation to unit testing WCF services. 

It may be possible to expose a library directly in WCF but I would rather see an architecture like the one presented in the Service Software Factory with a clear separation of concerns.

In my opinion it makes little or no sense to create unit tests for anything but the layers below the Service Interface Layer (SIL, see below). While it is possible to create unit tests for the the Service Interface Layer it makes much more sense to build integration tests for this layer. OperationContext and every bit of logic related to information kept here should be handled in the SIL.

This also means that Service operations are implemented in the SIL and that this is where we filter all the transport / protocol logic (if any) away before the call is forwarded to the business layer.

Comments

• Anonymous
  December 04, 2006
  In my previous post about unit testing WCF services , I hinted at the need to perform integration testing

• Anonymous
  December 04, 2006
  Dude, unit testing always makes sense when it's possible, since they are the simplest (and thereby cheapest) form of test you can write :) As long as you can test the service logic with unit tests, I see no need to go the extra length of writing integration tests to achieve the same result. On the other hand, as my new post admits, there are plenty of reasons to write integration tests against the SIL as well, so I'm only saying that depending on what you need to do, you can do either the one or the other. But I will still maintain that separation of concerns is desirable, and that you shouldn't litter your business operations with WCF-specific code. That doesn't mean that you can't place your custom authorization managers, message interceptors, etc. in the SIL (and even in the same library).

• Anonymous
  December 04, 2006
  Agree.