This project is read-only.

Detailed Scenarios for using MockingBird

Contract-First Development

In Contract-First development, the specification for the service contract/interface is first developed before the actual implementation. There are two approaches for Contract-First namely Code-First (where you write the interface in C#/VB.NET and use that code to generate other artifacts such as WSDL or other metadata endpoints) and WSDL First (where you first write the XSDs for the messages and compose the WSDLs and then use that to generate the .NET code.

In the current version Mockingbird requires a WSDL but does not prescribe whether the WSDL should have been created first or the .NET code. The GUI parses a given WSDL and sets up the service so as long as the WSDL is valid and all the schemas can be discovered (embedded or linked) there should be no problem. The engine does not depend on the WSDL (although the WSDL location is specified as an optional element in the configuration schema).

There are two use-cases within the Contract-First development scenario.
• As a web-service consumer
• As a web service provider

As a web-service consumer

You may be integrating with a web-service that is external to the immediate system under development. This may be a third party web service (installed on or off-premises) or a web-service interface to another subsystem that a part of your team is building/has just built. Often when integrating with third-parties, we are first provided with WSDLs and Schemas and eventually we get access to a functioning system.

In this scenario, Mockingbird gives you complete control over the requests that you send to it and the responses you get back. This means that you can concentrate on making your calling application work and handle responses correctly, without worrying about unpredictable behaviour from the external web-service. As such it is an excellent unit/integration testing tool. Because the message responses are simply Xml files on your local PC you eliminate the following difficulties:
• Someone may be developing the web-service and taken it off line
• Or messed it up so it throws an exception
• The underlying database might be down
• You or your web services might not have the right permissions to call it
• You might not be able to call it twice with the same data (say if you’re testing your delete functionality).
• Licensing Issues: The vendor may allow you to install only one instance of the web-service which makes it very difficult, if not impossible, to run parallel environments like DEV, TEST, UAT with their own datasets & versions.

As a web-service provider

You may be providing a new web-service to an external partner or another feature team. In these situations it is helpful to be able to work out the specifications for the message and data contracts first and then embark on development (with the appropriate processes in place for change-control etc).
In this scenario, you can rapidly provide a web-service interface for the consumers so that your development schedules are not too dependent on each other and if the contracts change as you develop, updated webservice interfaces can be quickly provided without the hassle of providing a complete install and all the underlying infrastructure that goes with it.
Additionally the other side of the consumers points listed above also apply to you as a provider.

What about testing against the actual system?

Of course you do eventually need to perform functional and integration tests against the actual external system because it is not possible to simulate all the exceptions and data conditions of a line-of-business application in a mock service. Mockingbird just helps you get a working interface with a comprehensive base of response messages that will help in getting development off the ground

As an Environment Isolator

Just as we need predictable responses for unit tests, it is also beneficial if our build / dev servers don’t have to rely on external web services being available. instead of depending on an external system, we host Mockingbird on our local webserver. We can then change the responses it sends back to suit our purposes, and define simple business rules that determine which of several messages to return to us. Network problems are eliminated, you are not at the mercy of external changes, and your tests are endlessly repeatable. Because it is hosted locally, your tests should also work on any other machine that downloads has all the config files to support Mockingbird.

Last edited Jan 13, 2009 at 12:40 PM by santoshbenjamin, version 1


No comments yet.