WCF Service Test Module with Multiple Dependencies

Question

I definitely hope someone can help alleviate my frustration. I am trying to find a good unit test method for my WCF service implementation classes, but every resource that I found providing a solution is limited to services with only one method / operation.

In my case, I have a service class that contains several service methods / operations. The purpose of the service class is to provide an interface for the behavior that is implemented in the main application. Thus, each method / operation is responsible for:

• accepting the request object from the caller
• checking object properties
• instantiating an applicable Command object that performs the operation
• displaying the Request object of the property for the Command object.
• Command object execution
• matching results with the answer Object
• returning a response to the caller

In addition, the service method handles all exceptions and returns a WCF error.

We use Spring.NET for IoC (DI) and AOP. The service class is created by Spring, which allows us to use the Spring ParameterValidation aspect to complete step 2. By default, we also use Spring for step 3.

For the most part, all this works great. However, when it comes time to write unit tests to test the behavior of a service method, I get stuck trying to find the right way to deal with service dependencies on multiple Command objects (one for each method).

Let me be clear, I have no problems mocking Command objects (we use Moq, btw), and I have no problem testing a black box. I am trying to do a white box check in internal logic, for example, to make sure that step 4 is running correctly or if the Command object throws an exception, the service handles it correctly. For them, I use mock instances of the Command object.

The problem is finding the best practice for a scenario in which the test object has several dependencies - especially when I am interested in only one of them for the test that I run.

The constructor's approach to DI is simply impractical, since I need to have as many arguments for the constructor as the methods on my service (and this can be quite a lot). I'm interested in Setter-injection, because setters will exist only for testing purposes - and in many cases there will be many of them.

The service is intended to delegate step 4 to the virtual method, which by default uses Spring to instantiate the Command object, but van is overridden to return the layout using the inherit and override approach. But it also turned out to be cumbersome.

So, after you shed an article after an article on the Internet that demonstrates various solutions, but, as I said, only ever reflected a service with one method / operation, I am looking for some recommendations for an approach that will be easy to implement, support and extend when working with real services that contain several methods and several dependencies.

Keep in mind that I cannot use Spring to introduce mocked Command objects, because I need layout references to configure them and test the behavior of the method. (Not to mention that my tests then depend on Spring, working correctly.)

Answer 1

It looks like you have already done most of the hard work.

Since you are already using a DI container, maybe you can just create and enter Mocks, which will intercept step 3. Then you can get what the DI container received, and how to test to check the first two steps, then you can get the Mock returns all you want to check is the remaining steps.

You have already made a great deal of dependence on spring.net and move on to the fact that the extra distance to give your layouts and power tests their use sounds reasonable to me. There should be a way to temporarily change your configuration to use a specific Mock. If you are not considering a simple factory that your service will use so that you can use your Mocks.

Answer 2

Usually I have classes of service - these are just subtle facades for real functionality. In this case, you might think about not testing the service itself, but delegate all calls to one of several internal objects that will be individually more verifiable, as they will be more specific.