ASP.net: Unit testing with dependency on web service proxy class

Question

Let's say I have a class like the following:

public class Test{
        private RemoteDoc.Documentation docService = new RemoteDoc.Documentation();
        public Test(){}
}

So this makes it difficult to unit test because there is a dependency on the proxy class. You can pass in the object via the constructor like so:

public class Test{
        private RemoteDoc.Documentation docService;
        public Test(RemoteDoc.Documentation serv)
        {
               docService = serv;
        }
}

Now in my unit tests I can instantiate the Test class and pass in a mocked object into the constructor. However, this solution isn't ideal because now other classes have to know about RemoteDoc.Documentation proxy class and have explicit references to it. What's is a good solution to this problem?

EDIT: To be more clear, RemoteDoc.Documentation is a proxy class for a web reference. Think of it like if you were using salesforce.com's api and all you really have is the wsdl and disco files.

Answer 1

Your proposed solution that involves passing in the dependency via the constructor is, in fact, ideal. It is a well-known Dependency Injection (DI) pattern known as Constructor Injection.

What at first seems like a weakness turns out to actually be a strength. While it is true that every single consumer of the Test class (in your example) must now supply some implementation of the proxy (I hereby assume that the proxy is an interface or abstract base class), they can supply any implementation of that abstraction and not only that which you originally had in mind. Congratulations: you have just opened your class for extensibility!

This still leaves the question about where do you actually place the responsibility of deciding which dependencies go where? You should do this in the root of the application in a place called a Composition Root. This is explained in more details over in this SO answer.

You can use a DI Container to Auto-Wire your depdencies. Some common DI Containers are:

• Castle Windsor
• StructureMap
• Spring.NET
• Unity

Answer 2

I second Mark's approach. For completeness another option is as follows:

public class Test
{        
     private RemoteDoc.Documentation docService;     

     // Constructor providing default for docService
     public Test()
     {
         docService = new RemoteDoc.Documentation();
     }   

     // Constructor for injection
     public Test(RemoteDoc.Documentation serv)       
     { 
          docService = serv;        
     }
}

This means you have a default implementation as well as having the option of plugging in a different implementation. Useful if you don't want to use a container.

I've used both approaches in the past. When developing non trivial software the DI container approach is usually a better way to go.

Answer 3

I like RichardOD's approach. One refinement that is useful for unit testing is to use a mock object instead of accessing the real web service. This will mean your tests will be decoupled from any external services, and run faster.

You can do this if the code is changed to look like:

public class Test
{        
     private RemoteDoc.IDocumentation docService;     

     // Constructor providing default for docService
     public Test()
     {
         docService = new RemoteDoc.Documentation();
     }   

     // Constructor for injection
     public Test(RemoteDoc.IDocumentation serv)       
     { 
          docService = serv;        
     }
}

Then you create a mock documentation object using a mocking framework like:

• Moq
• Rhino Mocks

... and pass it into the Test(RemoteDoc.IDocumentation serv) constructor.

Since RemoteDoc.Documentation is a concrete class, you can make it inherit from RemoteDoc.IDocumentation using a partial class:

namespace RemoteDoc
{
    public interface IDocumentation
    {
        // public functions you want to mock go here
        string GetDocumentation();
    }

    public partial class Documentation : IDocumentation {}
}

Answer 4

Note that this is much easier using WCF, since a service contract is already an interface. Your mock class need only implement the interface.

Answer 5

How about this approach? You will have to write more code to support the functionality in the proxy class. But it will gives you the flexibility for unit testing.

public interface IDocumentation
{
    // Add whatever functionality you need from RemoteDoc.Documentation
}

public class RemoteDocumnetation : IDocumentation
{
    private RemoteDoc.Documentation docService = new RemoteDoc.Documentation();

    // Implements IDocumentation 
}

public class Test{
        private IDocumentation doc;
        public Test(IDocumentation serv)
        {
               doc= serv;
        }
}