Enhance Stubbing & Mocking With Service Virtualization

How does service virtualization relate to stubbing and mocking?

Deadlocks are endemic to parallel and Agile development environments, where different teams are simultaneously working on interconnected system components — and each team needs to access the other’s components in order to complete its own tasks. But when a team ends up waiting for access to dependent functionality, agility is stifled.

One approach to working around such contention for testing resources is for each team member to create simple stubs or mocks to replace the dependent resource. However, there are serious risks associated with this approach:

• The stub might not correctly represent the full scope of the component’s final behavior.
• Different team members might be developing and working off of different stubs based on different assumptions.

In both cases, the end result is that quality and/or productivity will be compromised. If the application is built against a faulty assumption, defects could be introduced (if this discrepancy is not detected) or rework will be required (if the discrepancy is detected). Moreover, if the application is tested against a faulty assumption, there is a significant risk that the “validated” functionality may not work actually work as expected and that other defects may have been overlooked.

How Service Virtualization Helps with Mocking/Stubbing

While stubs are created from the perspective of the test suite in order to “skip” unavailable system components, service virtualization involves constructing virtual assets to make the behavior of constrained components available to the entire team.

Users can create the asset, then validate that behavior with the dependent parties if necessary. With the asset centrally provisioned, all team members will be accessing the same asset, which is expressing the expected behavior. This allows absolute consistency and reduced risk of defects slipping into the final product.

Truly scriptless service virtualization helps accelerate virtualization adoption, whether simple or complex test assets are needed. A breadth of message types means better support for your intended application domain.

Service Virtualization Emulates More Realistic Behavior

Moreover, service virtualization can represent much more realistic behavior than simple stubs and mocks. You can capture current behavior from live systems or recorded traffic, update the behavior as needed to cover the intended modifications, then configure this virtual asset by parameterizing its conditional behavior, performance criteria, and test data.

You can also easily modify the virtual asset to produce the appropriate assortment of fault conditions, exceptions, etc. that should be exercised in order to validate the full range of system behavior — including its ability to respond correctly (or at least fail gracefully) in various exceptional situations.

Virtualization enables complex test conditions (e.g. “what-if,” security, fail-over, performance, and negative test scenarios), and uncovers hidden performance issues in your application under test by controlling the  performance of the service, for load testing or slow network simulation. Users can easily configure a variety of scenarios by dynamically data-driving service virtualization from external data sources, or built-in data repository infrastructure.

Service Virtualization Represents Composite Behavior

Virtual assets created from service virtualization do not need to operate as silos; they can represent composite behavior. For example, a call to transfer funds in one virtual endpoint can trigger an account balance update at another. This allows virtual assets to behave in a stateful manner, and allows you to easily model the behavior of an entire system — even if the behavior crosses multiple connections, protocols or interfaces.

A critical part of creating realistic virtualized dependencies is having stateful behavior. In other words, a virtualized dependency retains its state from test run to test run. To have trustworthy and reusable virtualized services it’s critical that they can mimic the real service sufficiently to provide meaningful results back the application under test which, in turn, requires stateful testing. In addition to statefulness, there is also the need to simulate changes in state based on different potential inputs, virtualized service need to extend this stateful behavior to enable state transition testing.

Service Virtualization Enables Boundary Testing

Sometimes in order to reproduce a defect, data that doesn’t normally exist in the real environment is needed. By loading synthetic data into virtual services, all sorts of out of bounds responses are possible that are extreme edge cases in reality. This makes it much easier to perform security and boundary condition testing because you can simulate exactly the responses you are looking for.