DEVOPSdigest

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.

Comparing Stubs and Mocks

Stubs and mocks perform some of the same functions as service virtualization, but 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.

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.

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 asset with appropriate request/response behavior. 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: 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.

DevOps teams often use two main types of SV:

■ Test data virtualization

■ API service virtualization

Data Virtualization

There's no better test data than fresh production data. For testing, traditional test data management (TDM) solutions focus on cloning production data and massaging it to be reused for testing.

Although this is an efficient approach to obtaining realistic data, it does leave quite a few blind spots and comes with an expiration date. Additionally, you have to consider the volume, privacy, and complexity as you scale tests to full-on performance tests and implement complex test scenarios.

Service virtualization is a technique that allows you to simulate the behavior of dependent systems or components during testing. You can create virtual versions of the assets and the relevant data. This can be useful in addressing the "test data problem" because it allows you to test the performance of your system or application without having to rely on real data from external systems.

Developers and testers can use service virtualization to create a replica of the dependent systems or components on which the system or application relies. These virtual versions can mimic the behavior and response of the real systems or components, allowing you to test your system or application in a controlled environment without the need for real data.

Service virtualization can help address the test data problem in the following ways.

1. Reduce the need for large volumes of test data: Using virtual versions of dependent systems or components enables you to test your system or application with a smaller volume of test data.

2. Protect data privacy: Service virtualization allows you to test your system or application without exposing real data, protecting the privacy of users and customers.

3. Simplify data complexity

4. Improve data maintenance: Quickly and easily update the behavior of your virtual systems or components so it's easier to maintain and update the test data as needed.

5. Reduce data storage requirements: By reducing the amount of test data that you store and manage, you can minimize storage and infrastructure requirements.

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.

Go to: Go Beyond Stubbing and Mocking: Discover Service Virtualization - Part 2

Learn more about how companies deploy service virtualization as part of their software testing strategies at the Automated Software Testing & Quality Summit, hosted by Parasoft on May 16.