ALM Best Practices

Service Virtualization and Stubbing/Mocking

Last week, we answered 2 frequently-asked questions about service virtualization: what is service virtualization and how does service virtualization relate to Application–Behavior Virtualization. This week, we'll answer another common question: 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 others' 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 deadlocks 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

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

They 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.

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. Moreover, 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.

 

Service Virtualization Represents Composite Behavior

Virtual assets creating for 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.

 

***

Photo Credit: Duncan~

If you’d like an overview of how Parasoft's service virtualization provides easy access to the constrained components that impede development and testing, read our Service Virtualization eBook or visit the Parasoft Virtualize page.