Stubs / Mocks vs. Service Virtualization..? Yikes

Great question. Basically, stubs disconnect a test suite from an environment and service virtualization emulates an environment in order to better exercise the true intent of a test.

In more detail...

Stubs provide replacement implementations for objects, methods, or functions in order to remove external dependencies. Stubs are typically used during unit and component testing for two main purposes: 1) To isolate the code under test from the integrated environment 2) To enable testing to proceed when it is not possible to access an external resource or problematic method/function/object.

If you're trying to write a unit test and need to replace a simple call to a database, external libraries (e.g., file I/O) or other system API, stubbing might be perfectly suited for your needs.

While stubs/mocks are typically used to “skip” unavailable system components, service virtualization allows team members to emulate environments (or specific components) and make their behavior available to the entire team. For instance, service virtualization might be used to emulate the behavior of a dependent component (such as a 3rd-party service, database, mainframe, packaged application, etc.) that is evolving, not yet available, or difficult to access / configure for testing.

Service virtualization can represent much more realistic behavior than simple stubs and mocks. If you can access the dependent application, you can capture its current behavior in a "virtual asset" by recording from the live system. Alternatively, you can model virtual assets that represent the anticipated behavior. You can then configure this virtual asset by parameterizing its conditional behavior, performance criteria, and test data. Moreover, you can 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.

Parasoft, the c

We meant that SV can represent behavior more realistically than stubs can. 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.