WSDL.exe - generate interface as well as concrete class for easy fake/mocks later
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
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