Tutorial – Service Virtualize

Service Virtualization

What Is Service Virtualization?

Service virtualization lets you create a simulated version of a service. The simulated version is referred to as a virtual service. The virtual service does not need to duplicate all the functionality of the actual service.

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.

Service virtualization attempts to remove these test environment constraints by simulating the behavior of unavailable or difficult-to access dependencies, as depicted in below figure. This is done by modelling 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.

Why we need Service Virtualization?

• Agile and parallel development teams inevitably reach deadlocks as different teams are simultaneously working on interconnected system components—and each team needs to access the others’ components in order to complete its own development and testing tasks.
• Performance test engineers need to test vs. realistic transaction performance from dependent applications (3rd party services, mainframes, packaged apps, etc.), but it’s often unfeasible to set up such conditions.
• End-to-end functional testing is stymied by the difficulty of accessing all of the necessary dependencies—with the configurations you need to test against—at a single, convenient, and lengthy enough time.

 Service Virtualization provides access to the dependencies that are beyond your control, still evolving, or too complex to configure in a virtual test lab.

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.

Other dependencies could be like:

• Available for testing only in limited capacity or at inconvenient times
• Difficult to provision or configure in a test environment
• Needed for simultaneous access by different teams with varied test data setup and other requirements
• Restricted or costly to use for load and performance testing

Service Virtualization vs 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 behaviour 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 behaviour verification during test execution.

Below table summarizes the differences between these techniques 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 Centre 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

How Service virtualization fits in Software Development Cycle

• Developing and implementing virtual assets should be treated as software development. This includes following:
  Development of virtual assets should be made a specific and visible task in your overall software development process. In case of Agile/Scrum software development, for example, virtual asset development and maintenance should be taken as tasks on the Scrum board, assigned an owner, and ensure that it is accepted at the end of a sprint.
• Tasks related to the development, implementation, and maintenance of virtual assets should be planned in time and with an eye on what resources are needed.
• Virtual assets should be treated like any other software artefact delivered by a development team. This includes bringing those assets under version control and testing them to validate that they meet expectations.

Benefits of Applying Service Virtualization to Software Development Life Cycle

The use of service virtualization to simulate the behavior of critical yet hard-to-access application components and dependencies in your software development life cycle has a number of significant benefits:

• It allows for earlier testing.
• It allows for continuous testing.
• It enables development teams to increase their test coverage.

Note that there are other benefits as well, but we will not be covering those in this chapter. Here are some examples of these additional benefits:

• The ability to closely replicate dependency performance characteristics for performance testing purposes
• The ability to replicate and fix defects faster
• The ability to prepare functional testing scenarios earlier and execute them faster

Earlier Testing (“Shift Left”)

When you have virtual assets that simulate dependency behavior at your disposal at the beginning of your software development activities, no more time is wasted waiting until every dependency is in place before you can begin integration and end-to-end testing. The ability to test earlier means that potential defects are uncovered earlier in the development process, when they are relatively easy, fast, and less expensive to fix.

The ability to test earlier in the software development life cycle is commonly known as the shift left of testing. Figure 2-1 illustrates this concept.

Continuous Testing

When the IT landscape of your organization is one with a lot of applications running on many different platforms, setting up and maintaining test environments requires a significant amount of time and effort.

With the burden of provisioning and configuring (possibly many) test environments out of the way, and with no more need to populate and repopulate these test environments with the appropriate test data before every test run, you can run tests against the exact same dependency in the exact same state over and over again.

An immediate benefit is that this improves the stability of a software system and enhances the trust stakeholders place in it. It’s one thing to see that a specific test or test set passes once; it’s another thing altogether to know that that system passed the same set of tests many times.

Another advantage is, in case a defect does occur, being able to recreate the state of the test environment with a single click of a button makes reproduction and root cause analysis of the defect much easier.

The ability to run tests over and over again, on demand, is also known as continuous testing.