Benefits of Service Virtualization Beyond Stubbing & Mocking

Service virtualization (SV) is a method that DevOps teams use to simulate components of an app’s behavior. Components are APIs, databases, networks, devices, and more. Teams use SV because some components of the project may be unavailable for a number of reasons, including:

• Developers are still developing them.
• They may be problematic to set up.
• They may be hard to access.
• Third parties may own them.
• They may be expensive or restricted.

Service virtualization is like a flight simulator for applications. The objective is for testers to test for functionality and deficiencies during development and to recognize potential problems, addressing them as early as possible so the plane doesn’t crash.

Using SV saves time, money, headache, and frustration. DevOps teams don’t end up with an “us vs. them” attitude when development grinds to a halt while waiting for their fellow team members to complete their part of it.

Service Virtualization: Getting Into the Details

• A virtual service is a “test double.” It’s often a software as a service (SaaS) and never works in process directly with functions or methods.
• To create virtual services and assets, developers can record traffic with a service virtualization platform rather than constructing the interaction pattern from the ground up.
• Service virtualization usually supports multiple protocols, such as MQ, HTTP, TCP, and others. A mock or stub often supports only one.
• Service virtualization tools frequently feature user interfaces that permit non-developers to use the tools for testing without having to know the details of the project.

Service virtualization tools can also replicate nonfunctional aspects of the system like heavy activity loads or slow connections and response times. Some virtual services have a group of stubbed responses for provided request criteria and send all other requests to an operating backend system. This is called partial stubbing.

Like mocks, service virtualization can include complex request matchers. These allow the test to return one response for many types of requests. Beyond simple mocking, service virtualization simulates a system’s behavior when it constructs and returns responses based on request data and attributes.

Comparing Stubs and Mocks

Stubs and mocks perform some of the same functions as service virtualization but, as we note, they aren’t as thorough or as flexible.

What Are Stubs?

A stub minimally executes an interface and returns hardcoded information that’s tightly connected to the suite of tests. Testing teams find stubs are most helpful when the test suite is uncomplicated and retaining the hard-coded information in the stub is not a problem.

Developers write stubs, usually for personal use, and they normally don’t share them because the stubs cannot operate between platforms and because of hard-coded infrastructure dependencies.

What Are Mocks?

A mock is a programmable interface “observer,” which verifies whether the development’s output meets the expectations the test has defined. Testing tools create mocks employing a third-party library, for example JMock, Mockito, or WireMock.

Testers use mocks when they have large test suites, where using a stub will not work (because each test requires a different data setup) or preserving them in a stub would be too expensive. Developers also write mocks for their own personal use and usually don’t share them for the same reason they don’t share stubs as mentioned above.

The Benefits & Challenges of Service Virtualization

The many benefits of using service virtualization include:

• Establishes a commonality so development teams can communicate with their fellow development and test teams and share artifacts. Teams also can readily exchange SV assets within the company.
• Easy to learn, even for non-IT people, so developers can continue their work while testers use SV to test all aspects of a project, with the resulting reduction in labor costs.
• Supports many protocols and are able to record traffic. Ideally, these traffic recordings can be used to automatically generate virtual assets.
• Reduces dependence on the availability of third-party components and there are no service charges for third-party databases, APIs, or services.
• Reduces time to market because SV lessens testing, and therefore, development time.
• Increases quality because testing is more thorough and accurate.

Some people say using service virtualization presents too many challenges. Parasoft provides solutions.

Challenge: “As opposed to testers or developers creating a stub or mock to test the project, don’t SV tools cost more?”

Solution: Not using SV complicates testing and adds to expenses. Check out how Parasoft addresses issues of complexity, expense, and other potential issues here.

Challenge: “SV systems are large and may not be right for my small company.”

Solution: Parasoft’s simple, value-based licensing scales with your company’s needs and supports large and small deployments with a mix of offerings.

Challenge: “To avoid a poor user experience, how can my company make sure the service virtualization package I choose is right for my needs?”

Solution: Parasoft’s experts explain the aspects to consider for selecting the right service virtualization tool for your company’s requirements in this whitepaper.

Data and API Service Virtualization

DevOps teams often use two main types of SV:

• Data service virtualization
• API service virtualization

Data Virtualization

Database maintenance and provisioning is often problematic. Database administrators may lack the training they need in these days of cloud-based operations or the skills they need to efficiently and effectively create reusable test data. Database service virtualization allows testers to “decouple” database layers, which subsequently allows team members to share and apportion the resources of databases as needed.

Using database service virtualization enables teams to continue building and testing with realistic data examples even if data sources are not available. Once the developer identifies the data source, s/he specifies the attributes the source includes. When a request passes to the virtual asset, it uses the simulated data source to produce environment-specific responses that are based on request factors. As the tester modifies the data sets, the simulated responses update automatically.

Database virtualization lessens the team friction that dependencies often cause. Work on the development can progress even though the actual data sources are not on premises. Teams can also employ a virtual database to migrate from one server to another one without interruption. This is an opportunity to save on the large infrastructure expenses traditional database management often incurs.

API Service Virtualization

APIs (application programming interfaces) are software intermediaries that allow two applications to communicate with one another. When you’re on your PC interacting on Facebook, or on your phone performing a transaction on a bank website or checking the news, APIs are at work, either upfront or behind the scenes. Complex applications may use many different types of APIs, which increases the difficulty of thorough testing.

When testers use service virtualization to test APIs, development moves along quickly and quality increases. Performance testing, third-party sandboxing, and load testing all help developers understand an API’s full capabilities during delays, and high load and heavy traffic situations. Testers can use service virtualization to test various message types and different protocols, such as JSON, JMS, WADL, and REST. They can use it for end-to-end testing, which provides multi-layer validation across a wide variety of endpoints. Other ways developers use API service virtualization include enabling testers to:

• See how various events and messages pass through complicated architectures.
• Test for extreme cases such as large volumes of calls or poor connectivity.
• Investigate failures such as slow response times, downtime, or inaccessibility of a downstream integration.
• Test for security gaps.
• Test even if some of the system components are unavailable.
• Test a concept before actually building a piece.
• Find the best API with which to integrate.

API Microservice Service Virtualization

Companies have found that microservices testing using service virtualization is quite valuable. Microservices are small parts of a larger system that companies have released independently or have changed or implemented at various times. When each service comes from a different place and environments, testing is difficult. Using API microservices virtualization, testers install only the microservice they’re working on, then virtualize the rest, saving hours of time.

Lessening Dependencies

Reducing dependencies is another advantage of SV API testing. When developers “shift left” and involve QA from the beginning of system creation, SV API testing allows QA to jump right in and test “works in progress” in an exact replica of the environment – even if the developers have not released program details. This involves executing automated tests or continuous testing for direct feedback.

Empowering CI/CD Testing

Making sure the application works okay is not enough. It also needs to meet the system requirements and the broader business objectives of the project in addition to making sure all integrations are continuous and stable. API service virtualization empowers QA to test even when developers are still creating the API. Plus, it helps apps testers make sure APIs can integrate successfully with third-party APIs even if those apps are not yet ready for release.

Enhancing DevOps Transformation

To realize CI/CD (continuous integration/continuous delivery), a goal of automating 80% of testing is optimum. Testing APIs is hugely important because it helps to ensure that the entire pipeline still operates correctly after the team adds new features. This includes both external and internal APIs. Operations and development are becoming more and more integrated, so feedback loops and releases are more frequent. But when these teams only run UI test suites, the feedback loops can break. API service virtualization lets DevOps teams simulate dependencies early on so they can implement automated testing as the development progresses.

Iterative Designs

If your design environment is iterative, consider service virtualization. It allows you to quickly experiment with new ideas and approaches while avoiding constructing the entire API. The result is an Agile method to see if new collaborations and features work—minus large investments in time and resources.

Accelerating UI Testing

Service virtualization enables teams to describe common user interface integrations with web packages such as SOA and AJAX. This allows them to execute UI tests anywhere, anytime with no interruptions. Teams can simulate external environments, thus allowing more control over the data the web services return. Also, teams can even create and test UI integrations prior to the web services becoming available.

API Mocking vs. Service Virtualization

API mocking imitates components of software so developers can test for operability. The functions of mocking usually are context specific. In other words, the functions imitate a behavioral response to satisfy a particular development requirement. Further, API mocking isolates only an individual part of the application. It’s overly simplistic and forces developers to create new interfaces, which is complicated.

Stubs are similarly simplistic and awkward. Using both mocks and stubs are more time-consuming and limited in effectiveness compared to API service virtualization.
API service virtualization produces a much more full-function, realistic replicated environment. Benefits include:

• More flexibility because it isn’t tied to specific context or data.
• Developers can use API SV during production and testing.
• Reusable.
• Can be automated.
• Doesn’t require testing scripts or classes.

Service Virtualization Examples

Example 1. Your team is working on a large, complex legacy app with many dependencies. The present test coverage is low, in particular when the system dependencies are consistently not available.

Service virtualization enables you to log traffic when the dependencies become available. As a result, the team can later test with virtual services if you replay the traffic. This reduces the impact of the dependencies’ downtime for the team and the testers.

Example 2. Your team is working in a microservices-type architecture. One department has 10 testers and 20 developers. The group is in charge of delivering 70 small apps, which form a product.

Working teams test the applications individually and in isolation. While your team’s CI/CD system works well, the outside environment is not agile. Their APIs are slow and are often not available, which makes it difficult to set up test data.

To solve the issue, each team that interfaces with the third parties uses SV tools, and the acceptance testers use them during the CI build. The developers also use them for manual exploratory tests. The team then uses the tools in the primary integration build which runs all the applications. Finally, the performance test teams use the SV tools in the full stack performance tests.

Summary

Better than mocks and stubs, service virtualization serves your company well because it enables continuous testing, it’s more sharable, and it’s reusable. When added to your CI/CD workflow, SV reduces costs and shortens the time to market.