Did you know that service virtualization has been around for about two decades? That’s right. Even before the cloud was considered mainstream, we had service virtualization solutions to help in the development and testing of software applications. 

As a refresher, service virtualization is a technique that simulates the behavior of various components in software applications. 3rd-party services, APIs, databases, mainframes, and other components that communicate using common standard messaging protocols can all be virtualized. Service virtualization has been a great benefit in testing because it acts like a stunt double for all the back-end services that need to be tested but may not always have easy access to them. 

Mocks have also been around for decades and perform a similar function which is to make a replica or imitation of an object to be tested. Mocking is primarily used in unit testing where there are dependencies on other complex objects. To isolate that behavior a mock is created to simulate the behavior of the real object. Object mocking is often represented by tools and frameworks like Mockito. With the right objects mocked, the unit test can focus on what must be tested and not how to set various objects to the right state just to be able to perform particular test scenarios. The following diagram illustrates the concept of how a mock or virtual service steps in, in place of the real object.

Both mocks and virtual services play a valuable role in software testing. Traditional mocks, however, lack the ability to provide robust integration testing. For example, being able to test the full stack of an application’s behavior based on the varied responses from a dependent service is generally not possible with mocks. What happens if I want to know a particular HTTP response that is returned by an API? But it’s not only about having the dependency available. With service virtualization tools you have the entire behavior of the dependency under your control. For example:

  • You may use service virtualization to return responses that contain test data. This capability is very hard or impossible to load to the real service. 
  • You may use service virtualization to return responses that represent various failure scenarios that may be very hard to reproduce using the real service. 

Sometimes companies find themselves in between mocks and service virtualization. You might say they are between a mock and a hard place! They like the versatility of building mocks on the fly, but they know that they have limitations. Sometimes, developers live with the limitations to do some level of testing and still get code out the door.

When is Traditional Service Virtualization Too Much?

Service virtualization, for all its benefits, may also be a big hammer when a smaller one is needed for some types of testing scenarios. Here are some of the challenges with legacy service virtualization tools:

  • High Total Cost of Ownership – Traditional service virtualization solutions are expensive
  • Expert Setup Often Required – Most companies have a team that handles the setup and administration of service virtualization
  • Often On-Prem Only – Most service virtualization tools are not cloud-based

With all its versatility, service virtualization, for some companies, may be too costly, too complex, and too time consuming for the benefits it provides. Sometimes developers are looking for a lightweight and faster way to implement virtual services. They want the benefits of virtual services without the headaches and delays of traditional service virtualization solutions.

What are Intelligent Mocks?

Basically, intelligent mocks provide the best of both worlds; the agile capabilities of mocks combined with the robustness and depth of service virtualization. A developer (or tester) should be able to configure intelligent mocks for their tests by themselves without waiting for another group within the company to handle their requests. This is possible when the solution is cloud-based and agile.

Intelligent mocks can be part of a testing platform where services are delivered to the developer or tester for any testing scenario (e.g., unit testing, UI testing, performance testing, chaos testing, etc.). Because this solution is cloud based it is cheaper to deploy and cheaper to maintain. Ideally intelligent mock services would be comprised of:

  • Mock Services

A lightweight HTTP only virtual service which can scale horizontally and vertically and provide rapid time to value with specs such as Swagger and WSDL or transactions (R/R pairs). Runs on the cloud and doesn’t require on-premises deployments that are difficult to maintain.

  • Asset Catalog

A central catalog to store all service virtualization related artifacts for collaboration. Fosters sharing and re-use of artifacts between developers and testers so that complex rework of assets is minimized.

  • Virtual Service Environment (VSE)

A containerized, on-demand VSE to deploy multiprotocol advanced virtual services without any component dependency on legacy service virtualization platforms. Spin up/down a dedicated VSE during test execution. All tests utilizing virtual services need to be hosted in a virtual service environment. 

  • (Test) Data Driven Virtual Services

Provide comprehensive test data generated on the fly for each mock service in a variety of scenarios and types. The ability to build test data quickly and compliantly to avoid common issues with privacy regulations.

Perhaps the key to lightweight service virtualization solutions is this last point regarding test data. An essential aspect of every test execution is the test data. Each test is driven by data. The more comprehensive the data, the more detailed and high quality the test scenarios will be. But getting data is not always easy, and it’s a time-consuming process. The source of this data could be hard-coded directly into the test while some rely on a spreadsheet to lookup this data or even hook up to a database at runtime.

Note: When a traditional mock service is created, you can view the transactions which contain test data which was a part of the specification file. However, the test data in the mock service is static which means if that mock service contains five transactions, then during execution the responses will be based on those five transactions only, which would be permissible for basic testing. But the goal of mock services is to stand-in for the real service. This implies that the testing would change from basic to a more comprehensive approach as the teams start their negative testing or contract testing. This warrants more test data as a requirement.

Shift Your Service Virtualization Left

The benefits of service virtualization and mocks are clear. Without them our application development would be much slower and costly. The question for many development teams is about finding the right testing tools for the job. Traditional mocks still work but are limited in their flexibility for handling variable test responses, also known as chaos testing. 

Traditional service virtualization, on the other hand, provides a high horsepower solution but is sometimes more than is needed during various testing scenarios. The next advance for continuous testing brings the benefits from both service virtualization and mocks together in the right proportions. Intelligent mocks will speed development by placing the power of continuous testing further into the hands of more developers and testers.