WSDL.exe - generate interface as well as concrete class for easy fake/mocks later

Question

Is it possible to get WSDL.exe to generate interfaces as well as, or instead of, concrete classes when it generates proxys to a web service?

We're consuming a 3rd party webservice from an ASP.Net application, and have generated our proxy classes using WSDL.exe all well and good.

I now want to write tests against my wrapper and business classes by faking out the web service. There is no interface or abstract base class to the proxy, and they are marked internal, meaning I can't inherit from them without putting my Fake/mock test code into my business project/assemblies.

I could manually create an interface (using resharper) and edit the class, however if the 3rd part change their WSDL/web service I or my successors will have to also manually edit the interface, and automatically generated classes, which never seems like a good idea.

What's the most elegant way to fake or mock this service? Should I put the fake in the business project? Should I manually edit the files and create an interface? Should I do something completely different?

Answer 1

Right, prompted by Philip's answer I set off on one, and may have come up with a working solution. Using WSDL.exe I generated the interfaces (using the /si switch) and normal proxy classes, and added both to my business project.

I then created a new class which inherits from the concrete class AND implements the interface. This little class contained basically no code, as the inherited concrete members provided an implicit implementation of the interface members. The code compiled first time and I've been able to substitute this little "shim" (?adaptor?) class into my integration tests, and execute calls against the live 3rd party server.

I can now create other classes (mocks or fakes) which implement the interface, and substitue them instead of the "shim" class.

Edit: OK, I've worked a little further on this, and barring a few complications it's working.

The first significant issue is that the proxy classes are still marked "internal", so the derived (adaptor/shim) class has to be internal too. This isn't a problem if you put a Factory class into your business project/assembly which new's up the proxy classes, and returns them as the interface.

The second issue I found was that we were setting the URL and timeout properties of the webserice explicitly, but these are not included in the interface instead they are inherited from System.Web.Services.Protocols.WebClientProtocol via SoapHttpClientProtocol. Again, I dealt with this in the factory, as it's an implementation detail that I'm happy isn't in the interface.

Edit: This is still working out prety well for me while testing and developing our Facade. Since getting the proxy behind an interface I've also created a logging decorator class, which is capturing loads of example calls for use debugging, and when the 3rd party server is offline.

I've written up what I did in a little more detail here: http://www.flowerchild.org.uk/archive/2010/09/21/mocking-or-faking-or-maybe-stubbing-a-wsdl-exe-soap.html

Answer 2

You can run wsdl with the /serverinterface or /si switch to get interfaces for each binding in the wsdl. This is meant to give you the server-side skeleton from a wsdl document, but the interfaces should get you on your way - if I understand the question correctly.

EDIT -- After reading the comment, I believe that I misunderstood the question - you want client interface/concrete so that you can code to contract not implementation. The /si switch will probably not give you what you want at all.

I'm not aware of any switch that can give you this behavior, as wsdl basically creates one of three things: 1) client proxy classes: 2) server abstract classes (for creating a server implementation) 3) server interfaces (again, for creating a server implementation - this is just iface instead of abstract class) I don't see any way to force the client proxy classes to implement interfaces (other than INotifyPropertyChanged on data types)

Answer 3

I've always found that these generated classes are too large to mock easily (too many methods / property).

Rather, create a Facade or Repository that implements just the calls you need, and passes back DTO style objects with just the properties you care about.

Write some simple integration tests against the real Webservice, and then mock the simpler Facade in the rest of the tests.

An added benefit of this approach is that you effectively get an anticorruption layer, so changes to the 3rd party will only impact a small area of your code.