Mocking / stubbing "third party" services during integrated development

Question

The application I am currently working with is being worked on by 3 separate teams, each working away on different functional areas that come together at the end of the day. The difficulty is keeping the 3 teams always in sync and not having one team's issues affect another. I am looking for a way that I can stub out / mock the calls that are being made to some of these services provided by the other teams so that we can work separately most of the time, yet quickly switch back to integrated mode when needed.

Ideally I would like:

- during normal development, I could turn on a flag and those services will be mock services (for example, when I am just developing away on my part of the code and don't really care if the other team's service returns the right thing, just that it returns something)
- I don't want to have add code to check this flag everywhere in the code and if it is on, use the mock, else use the real thing... I just want it to automatically know to use the mock class when this flag is on

We are using Java 7 + CDI + Jboss. Is this possible to do with some kind of wiring or filters?

TIA.

Answer 1

Using Alternatives you can achieve this better ways, you can switch back to integrated mode when needed with disable alternative in beans.xml

CDI Alternatives are so good for the Mock service.

Instead of having to change the source code of your application, however, you can make the choice at deployment time by using alternatives.

Alternatives are commonly used for purposes like the following:

To handle client-specific business logic that is determined at runtime

To specify beans that are valid for a particular deployment scenario
   (for example, when country-specific sales tax laws require 
   country-specific sales tax business logic)

To create dummy (mock) versions of beans to be used for testing

Alternatives allow you to overwrite this at execution time using the beans.xml file - a simple deployment artifact.

A typical scenario would be to use different beans.xml for different environments and thereby enable mock-alternatives for components that you don't want to execute on your local / integration environments.

Using Alternatives in CDI Applications

Answer 2

In Spring-based applications (using dependency injection), I've accomplished this by keeping two application contexts, one configured to use stubs and one configured to use real code. I wrote some wrapper code to load the appropriate application context at the right time, but you could manage it other ways, i.e. with separate run targets that use a different classpath.

In terms of the stubs, I've often created them by hand (i.e. written stubbed services that wrap a spreadsheet of canned data or generate random data), but Mockito could be useful when building certain kinds of stubs.

Depending on what kinds of resources you need to stub (and whether you have a budget), another option is service virtualization. I don't have any direct experience using service virtualization tools, but my current client is using the commercial LISA tool to stub out a SOA service layer. I gather that several companies sell similar tools.