This project is read-only.

Alternative Approaches

Mocking Services and their endpoints is a useful part of testing and in many ways can improve the reliability of your code as you can control and force various data conditions and exception conditions. The approach that MockingBird takes (using HttpHandlers & Interceptors ) is not the only way to do this. I'll briefly describe two other approaches that you could take and also look at how MockingBird could help with those in future.

WSCF - Web Services Contract First

A tool that I really like and have used extensively (and am now part of the dev team too) is WSCF. The data contracts that it generates are much cleaner than XSD.exe and XSDObjectGen. Both "Classic" WSCF (ASMX) and "Blue" (WCF) create well defined interfaces and the corresponding SVC and ASMX files.
With either of these you can always fill out the code behind the methods and 'new' up the responses.

You can hardcode these reponses or use some other technique. In the days before MockingBird (and its predecessor) I linked up WSCF Classic with some utilty classes we wrote for serialization/deserialization etc so we put in a couple of lines of code in the ASMX stub to deserialze the response file into the class and return it. I have recently come across NBuilder and i think that this could also be used to create more 'intelligent' responses although I havent actually tried this out.

You can, of course, take this sort of approach to creating your stubs. However, there is a lot of maintenance involved especially when your contracts change (which they invariably do!) . Another downside is that now you need an actual physical endpoint for each endpoint you want to mock. Writing a generic endpoint would defeat a key part of WSCF, which is to encourage a strong typed approach to web services. MockingBird offers a lightweight alternative to this.

Using "Traditional" Mock Object Frameworks

If you have full control over the consumer (especially if you are writing it from scratch), then one good way to test is to use mock objects like MoQ or RhinoMocks or TypeMock.
  • Proxy generation tools (including WSCF) will usually generate an interface that the proxy code uses.
  • In the code that calls the proxy, instead of dealing with the concrete proxy class, you declare a member property of the proxy interface type (for example : ICustomerService instead of the concrete CustomerServiceProxy).
  • In the test, prior to calling the method of the class you are testing (which may be the service agent or the business logic - whichever depends on the proxy), you inject a mock interface (ie: a mock ICustomerService) and set expectations (for instance, you can set an expectation that the GetCustomerData method will be called and if it does, then you specify what data is to be returned).
  • Now when you call the method of your class under test, it will invoke the mock service and will get back the required data from the mock service.

There is no need to set up an instance of the service, update your config files, run into issues with ASP.NET permissions (happens all the time , doesnt it !!) etc. Now your tests of the main class are really unit tests and not dependent on environment conditions.

This is quite a popular approach to unit testing. It cannot substitute for integration testing, but it allows you to test with a variety of data and exception conditions and improves code quality. MockingBird is a different paradigm to mock objects since it is a actual endpoint and so is more like a 'functional test'

So, what about BizTalk?

With Biztalk you can mock dependencies when testing pipeline components but you cannot do that for orchestrations. So mock objects are of no use there. However, WSCF stubs or MockingBird are an excellent way to provide Biztalk with endpoints to call. All you need to do is set the URI of the mockend point in the binding file.

I do hope to be able to develop some Biztalk mock adapters as well which will allow you to use the 'real' transport channels but direct the calls to mock endpoints and also looking into the possibility of generating BizUnit tests steps for a given WSDL.

Last edited Aug 23, 2010 at 10:18 AM by santoshbenjamin, version 3


No comments yet.