Service Virtualization

Chapter 1. An Introduction to Service Virtualization

In this chapter, we learn what service virtualization is and how it relates to stubbing and mocking, two other simulation techniques that are used often by development teams to help them write and execute tests effectively.

What Is Service Virtualization?

Service virtualization is a method to emulate the behavior of specific components in heterogeneous component-based applications such as API-driven applications, cloud-based applications and service-oriented architectures. It is used to provide software development and testing teams access to dependent system components that are needed to exercise an application under test, but are unavailable or difficult to access for development and testing purposes.¹

A lot of modern software, such as Application Programming Interface (API)–driven or Service-Oriented Architecture (SOA)–based applications, consists of a number of interconnected components. Software development teams that want to access these dependent components (dependencies) during development and testing often find that these dependencies are unavailable or difficult to access.

There are several reasons for this:

• The dependency has not yet been developed or is under development. This is often seen when several development teams work in parallel on different components of a single system.
• The dependency does not contain appropriate test data. When test environments need to be configured with complex test data structures, often an (anonymized) copy or subset of production data is loaded into the test environment, without the development team knowing the contents of this dataset.
• Access to the dependency requires an access fee. This is often the case with Software as a Service (SaaS)–based third-party dependencies.
• The dependency is otherwise unavailable, unreliable, or acting in a nondeterministic manner. This is often the case with legacy systems.

Service virtualization attempts to remove these test environment constraints by simulating the behavior of unavailable or difficult-to-access dependencies, as depicted in Figure 1-1. This is done by modeling and deploying a so-called “virtual asset” that emulates those parts of the dependency’s behavior that are required to execute the desired test cases. Service virtualization is different from (and complementary to) other types of virtualization by focusing purely on behavior simulation rather than simulating entire systems.

Figure 1-1. Removing dependency access restrictions with service virtualization

Bottlenecks in the Software Development Life Cycle

In the previous section, we explored some of the reasons for the introduction of service virtualization. At the heart of these reasons are three main bottlenecks addressed by the 2015 voke Market Snapshot on Service Virtualization:²

Work is delayed while waiting for dependencies

No less than 81 percent of the participants experienced development delays due to access restrictions with regards to environment dependencies. For testing activities, the percentage is even higher: 84 percent of the participants experienced delays in testing activities for the same reason.

Access to required dependencies is restricted

On average, participants said they required 52 dependencies throughout the software development process (up to, but not including deployment into the production environment). However, only 23 of these dependencies can be accessed without restrictions.

Challenges in accessing third-party dependencies

Seventy-nine percent of participants reported that they experienced restrictions accessing third-party dependencies. These restrictions include access fees, time limits, and limited availability of suitable test data.

How Does Service Virtualization Compare to Stubbing and Mocking?

Development teams have been simulating dependencies required for executing different types of tests (such as unit tests and integration tests) for a long time. Two techniques that have been, and still are, widely used are stubbing and mocking:

• Stubs are objects that replace a dependency by providing predefined responses to input delivered during tests. Stub behavior therefore is predetermined and fixed, making stubs suitable for state verification during test execution.
• Mocks are similar to stubs, with the difference being that the behavior of mocks is defined during test initialization. This means that two instances of the same mock can behave differently, depending on their initialization, which makes them suitable for behavior verification during test execution.

Table 1-1 summarizes the differences between these techniques and service virtualization:

Table 1-1. A comparison between stubbing/mocking and service virtualization

Stubbing and mocking	Service virtualization
Used mostly to support unit and unit integration testing	Used primarily to support system, acceptance, and performance testing, although it can be used to support unit and unit integration testing just as well
Created and used mostly by developers	Can be created by any authorized individual and then shared and used within the team or across teams
Used mostly within the confines of a single team or project	Can be used at an individual team level, across teams within the same project as well as throughout the organization; for example, through a dedicated service virtualization Center of Excellence
Does not scale well to support larger projects and test scenarios	Scalable and reliable solution, able to support large projects and test scenarios
No support (or need) for data-driven stubbing or mocking	Supports creating flexible, data-driven virtual assets
No support (or need) for wide range of message and transport protocols	Supports a wide range of message and transport protocols

From this comparison, you could conclude that service virtualization takes the support for testing that is provided by stubbing and mocking to the enterprise level.

Now that we have seen what the concept of service virtualization entails, in the next chapter, we’ll take a look at how we can make it an integral part of the software development life cycle.

¹ https://en.wikipedia.org/wiki/Service_virtualization

² This market research was carried out in 2014 using 505 participants from a wide range of organizations, market segments, geographies, and roles.