C# - Mocking Out a Web Service

[bup]

For Unit Testing, I'd like to mock out web services that my app consumes.

From googling, I don't think it's possible for my web service (which is under my control) to implement an interface that is specified in the web reference.

Is there a clean pattern anybody knows of for replacing a real web service with a mock, for ease of testing?

[friedo]

I'm not too familiar with the way C# does things, but in my work when we need to do this sort of thing, we generally make a class which implements the API for the web service, and which uses a HTTP client library (or SOAP, whatever) to do its thing. Then for unit testing we mock the HTTP client library, and leave the API class alone. Our mocked class then pretends to be a server and feeds HTTP responses back when requests are executed.

[bup]

So you just manually implement an interface that the compiler doesn't enforce?

So you have a service called TheService, for instance:

public partial class TheService: HttpClientProtocol
{
 public object func1(){}
 public object func2(){}
}

and an interface and implementation locally?

public interface IOurWrapper
{
 object func1(){}
 object func2(){}
}


public OurWrapper : IOurWrapper
{
   public TheService TheService;

   public object func1()
   {
     return TheService.func1();
   }

   public object func2()
   {
    return TheService.func2();
   }
}

I was hoping for something cleaner, but if that's what it is, that's what it is.

[LSLGuy]

If you're consuming a traditional SOAP web service, then your code is typically interacting with the proxy class which Vis Studio (or WSDL.exe) generated for you. That proxy class is part of your project and under your control.

There's nothing to preclude you manually altering that proxy class to replace the real http calls with mocking code of your own. Then regenerate the proxy when you want to go live.

Or better yet, take a copy of the valid proxy proxy class & rename it, then alter it into a mock class. Then have your consuming code switch between using the real & the mock class by using a compiler variable to switch between embedding "using myRealProxyClass;" and "using myMockProxyClass;" statements in your consuming code.

In my experience consuming 3rd-party SOAP services, the biggest problem is that the wsdl / SOAP spec does a good job of defining the syntax of the interaction, but is real weak on semantics. So you can spend a lot of effort making a mock which reflects how you think the service works, but doesn't reflect how it really works, particularly in corner or error cases.

And so your code passes all your unit tests & still fails miserably in dealing with the other guys' quirks.

[LSLGuy]

You can even go so far as to generate the proxy class into its own assembly. And also generate your mock proxy class into a separate assembly with the same namespace & class names.

Then you can test live or mock by controlling which physical dll file is present in the bin or GAC of your test environment.

I would strongly avoid the idea you coded above with a layer of interface to add another layer of abstraction to the proxy class. Just more opportunity for maintenance headaches in vNext.

[bup]

Originally Posted by LSLGuy

You can even go so far as to generate the proxy class into its own assembly. And also generate your mock proxy class into a separate assembly with the same namespace & class names.

Oohh...not bad. I shall consider that strongly.

[Khadaji]

Stack Overflow is a good source for tech questions, and here is a link to a blog I found on that site.