What's the Difference Between Virtualization & Mocking

Defining API Virtualization

Let’s start with a simple definition; API virtualization is the process of using a tool that creates a virtual copy of your API, which mirrors all of the specifications of your production API, and using this virtual copy in place of your production API for testing.

Instead of setting up a whole separate server stack to mimic production, API virtualization aims to simulate the minimum behaviors of one or more API endpoints.

To illustrate, API virtualization is the equivalent of allowing you (or, in this case, your testing team) to taste a cake – its flavor, texture, and all – before it has finished baking.

With API virtualization, your development teams can create virtual APIs instead of production APIs, enabling frequent and comprehensive testing even when the API is still in the midst of being developed.

By emulating behaviors and specifications that will be present in the final production API, virtualization allows for testing much earlier in the development process, removing key bottlenecks that would otherwise delay production and time-to-market. More and more companies are using virtualization to improve productivity, reduce testing costs, and deploy higher-quality APIs in a shorter timeframe.

By quickly and easily removing dependency constraints across your organization through virtualization, you can gain a competitive advantage over other companies still waiting in the linear-development limbo.

API Virtualization vs. Mocking

API virtualization is often compared with mocking, but they’re not the same thing. Mocks are imitation software components that are used by developers to emulate real software components for testing purposes, which initially sounds a lot like virtualization.

However, one of the biggest distinctions between mocking services and virtual APIs is that mocking functions tend to be very context-specific, simulating a specific behavioral response to fulfill a certain development need at a certain time (i.e., injecting a missing dependency in order to bypass its absence, or temporarily test its presence, perhaps in isolation from the rest of the application under test).

API virtualization, on the other hand, delivers—for all development intents and testing purposes—the same behavior and functionality for any developer or tester who wants to use the API, at any time.

Thus, once they’re created and exist as part of a projectwide test environment, virtual components eliminate the need for individual developers to write and rewrite their own mocks, saving time and effort for all concerned.

API Virtualization v. Service Virtualization

Service virtualization typically refers to the process of simulating many or all components in an application stack. Traditionally, enterprise service virtualization solutions require standing up a full-stack of resources, training and management over software suites, and incur an enormous financial burden with entry costs into the hundred-thousands.

api virtualization vs service virtualization

The total cost of ownership over an enterprise service virtualization solution, typically in the range of $50,000 - $200,000, includes:

  • Time identifying an appropriate solution
  • Initial Licensing costs
  • Implementation and professional services costs
  • Cost to reconfigure virtualization strategy due to project changes
  • Employee training

The magnitude of these costs can often be overwhelming for agile project teams either just getting started on implementation of a service oriented architecture (SOA) or formulating a larger enterprise API strategy.

Delays in budgeting and purchasing such a costly solution prevent teams from being efficient in their projects long after the need for service virtualization is realized.

API virtualization, on the other hand, is a ground-up attitude to mimicking system behaviors and does not assume that an entire environment is required in order to simulate realistic behavior, just what is necessary.

Service virtualization itself is only a supportive task to building the actual system, and any time spent on it is time not spent on building or testing the actual system. Therefore, minimizing the amount of work and time it takes to configure virtual APIs improves both opportunity cost and minimizes unnecessary enterprise licensing costs.

In essence, service virtualization mimics an entire system, with all its complexity.

When working with API virtualization, the only virtual asset is the API, which makes the virtualization itself a significantly easier process. Far fewer skills and much less knowledge about an enterprise service virtualization strategy is required for these teams to inherit the benefits of virtualizing one or more of their APIs.

5 Best Practices for API Virtualization

1. Use realistic data and examples to drive responses

This allows you to link your tests and mocks with accurate data to generate realistic, real-life scenarios.

2. Isolate API operations

Imagine you’re testing a banking transaction that involves getting the balance, updating the balance, and committing the balance of an account. All you want is to test one of those operations. Virtualization allows you to isolate and test that one scenario so that you can ensure proper test coverage.

3. Quickly change responses to simulate errors

A proper API environment will allow you to do a lot of edge case testing so you can quickly change your responses and error codes, especially when dealing with a live and robust API such as Twitter’s.

4. Simulate network conditions and server capacity

A sophisticated environment will give you the ability to change the capacity or bandwidth of your network and the capacity of your server so you can test various scenarios your customers might encounter. If your customer is in an area with poor bandwidth, you would want to know how your application would respond.

5. Load test on virtual APIs, not production APIs

The right environment solution will allow you to conduct load testing. Whatever you decide to do, if you are conducting load testing, don’t use live environments. You don’t want to be throttled and spend copious amounts of money because you’re hitting a third-party API a million times.

Remove dependencies in your testing pipeline by virtualizing RESTful, SOAP, TCP, JMS, and other web services with ReadyAPI.

Read next:

What is Service Virtualization

Sharing and Automating Your Virtual Services

DevOps and Agile API testing