BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Service Virtualization as an Alternative to Mocking

Service Virtualization as an Alternative to Mocking

This item in japanese

Lire ce contenu en français

Mocking via dependency injection is often a messy endeavor. For even the simplest of applications it often involves creating new interfaces, taking on a dependency on an IoC Container, and in general adds a lot of unnecessary complexity. And after all that, you still have to write the mocks themselves, many of which aren’t useful for anything besides simplistic unit tests.

Products such as CA Lisa Service Virtualization offer an alternative approach. Rather than mocking individual classes, these testing tools allow you to mock entire services at the network level. From the application’s perspective it is talking to a real service backend, even though in reality that backend may not even exist yet.

There are two common ways of setting up a virtualized service. The first is to start with the contract (e.g. a WSDL or other protocol-specific descriptor) and create pre-determined responses. This can be done manually using normal Java or .NET code, or you can use a commercial product. An advantage of this method is that the team writing the component doesn’t have to wait for the real version of the service to be completed. The downside is that the real version needs to actually match the fake one, which becomes a questionable proposition as timelines become longer.

The other route is to use traffic recordings. A tool sits between the component under test and its down-stream dependencies. This tool basically acts as a proxy, gathering information about how the components interact. Later those recordings can be used to simulate the conversation between the component and the servers it depends on.

Both routes are viable for most communication protocols. With the right plugins and filters, the test tool should be able to understand message queues, REST, SOAP, raw TCP, or any other means of exchange.

Rate this Article

Adoption
Style

BT