What Is Web Service Virtualization?

Web service virtualization is practice of creating a virtual service that works similarly to the real API you are creating. The virtual service imitates the real API: it defines operations that clients of your real API will call, receives client requests and simulates responses. Virtualization is also called isolation, simulation or mocking, and virtual services are called virtual APIs or web service mocks. You use virtual services when you cannot use a real service.

Advantages of Virtualization

By creating virtual services, you can emulate the work of third-party APIs that your service uses.

Imagine, for example, that you are working on a web service for some bank. Its API might have an operation that creates a bank account. To do this, it might need to send requests to other web services to verify the social security number of a client, their credit history or driver license. It’s quite possible that using real services is slow or inconvenient for some reason.

To work around these issues, you can create virtual services that will emulate the needed external APIs and provide responses you need. Of course, at some point, you will need to check how your API works with live external APIs, but virtualization will help you develop your service and tests faster.
Virtual services help you create client code and tests before the API is created. You can even create tests for operations that have not been implemented yet. This gives you the ability to add tests to your automation environment in the development process. In other words, service virtualization gives you the ability to use test-driven development.
Teams can work in parallel. While developers are working on the API, your QA team can work on tests and have a full suite of tests ready when the service is ready for testing. You will not have downtimes when one team is waiting for the other to finish. This makes the financial argument for virtualization particularly strong.
You can create tests for unavailable resources. Web service virtualization enables you to create tests for operations that become unavailable because of an error. Also, it gives you the ability to create tests if the tested API is hidden by a firewall that cannot be opened for you or that you are not authorized to use. Placing a virtual service in an accessible place, for example, your local computer, will be a life saver.
You can create demos and conduct proof-of-concept meetings. A good virtual service is a cost-efficient way to be a wireframe or demonstration of what you are considering to build. This gives you a good base for making decisions about design and on whether to go ahead with development or not.
You can deliver the virtual service to your customer or partner. In some cases, you cannot allow your partners or customers to access your test systems. This can happen for security reasons or because the test environment is unavailable at the needed time point. In this case, you can export a virtual service to a file and then import it in ReadyAPI Virtualization on a remote machine.
You can reduce test costs. Some subsystems of your test environments might not be yours, and might be payable on 'per transaction' basis. This can be painful during testing, especially during load and performance testing. An easy way to get rid of this is to virtualize this subsystem. You can get both perfectly fine integration and tests with a virtual service, and the costs you can save can be substantial.
You can isolate subsystems easily. Sometimes, you may want to test a part of your system without having other subsystems affect it. Virtual services help you remove the dependencies by virtualizing all subsystems except for the one you need to test. These virtual services can be extremely simple, but reliable, fast and predictable. This gives you a test environment where you have removed all stochastic behavior, have repeatable patterns and can monitor specific subsystems well.
You can test a live environment before adding a web service to it. Placing a virtual service in a live environment can reveal problems with network resources, quirks in the server setup and configuration errors in external subsystems like system monitors. This can help you weed out the worst errors and behaviors.

Disadvantages of Virtualization

You may have to duplicate your work. After you created and used a virtual service for some time, in many cases, you will finally replace it with a real API. The value of a virtual service is only based on how well you can use this service during its life time. For that reason, it is a good idea to balance the efforts you put into the virtual service. You can get very far by creating a pretty rudimentary mock and then expand it as far as needed.

To switch your tests from a virtual service to the real API faster, in ReadyAPI, you can configure your virtual service to redirect (route) client requests to your real API. This will make the transition easier and seamless.

Some virtual services remain useful even after the developers implemented all the operations of a real API. See an example below.
Unless you are going to work with your virtual service locally, you will need to deploy and run it somewhere. It might be an issue to find a place (computer) where your virtual service will run. However, this is the same problem that you have with running real web services. So, to run your virtual services, you can use the same computers that you use for running real web services. This computer needs to have VirtServer or ReadyAPI installed on it.
The virtual service is a representation of a real web service, and it may be inaccurate. Most often, it is an ideal of the web service you are mocking: it does not have any service specifics and may have bugs. Engineers create virtual services in order to have a stable test environment, and quite often they remove a lot of complexities of a live environment from the service. Make sure that all stakeholders understand that the actual environment will introduce complexities. The functional tests you create in ReadyAPI will help you find the differences and fix the issues.
The virtual services you create may be way too good and way too lifelike, and so it may look tempting for management to extend the functionality of a virtual service and to move the service into a live environment. Do not do this! Web service mocking is for mocking and nothing else. It means that a virtual service will not provide real functionality, even though it looks like it might. Manage expectations. Even though the virtual service works fine, it does not mean that the real service will.

Best Practices of Virtualization

Despite the drawbacks described above, virtualization is extremely powerful when it is used correctly, and can save a lot of time and money for you. Below are some of best practices. Keep them in mind when creating virtual services.

Create a simple virtual service and expand it step by step

Use a very simple rule of thumb: your virtual service should be available within one or two hours after you start building it. This rule forces you to move quickly and focus on simple deliverables, which you probably will find surprisingly useful, but not quite good enough. Next step then would be to examine the needs and to expand the virtual service to create good tests.

Try using an iterative process: add enough functionality to create the next set of tests, create them, evaluate your needs and then move into the next iteration. As you move ahead, you will find that the next batch of functionality to be added to the virtual service is less and less critical and the cost for adding it will be higher and higher. At some point, you will find the balance of functionality and cost.

Agree on the virtualization scope

It is considered to be a good practice to discuss the virtual service with your teammates and future users and agree on how detailed the virtual service should be. The answer should not be plain and simple. Most likely, it will be somewhere between “very detailed” and “non-detailed”. Creating a lightweight mock means that you will be able to create lightweight tests, and creating a too detailed mock can be too expensive. Look at the factors like frequency of use, complexity, accessibility and business value to figure out a level of virtualization, and get a commitment for the scope from your team.

Once you have formed an idea of what your virtual service should be, work on getting an agreement with all stakeholders. This will make your life easier later in the project. If the stakeholders agree on what to expect from the service, things will run smoother, and you will not miss the important features and behavior.

Decide what you need to mock in depth

Choose what to mock in depth before you start working. Some interfaces might be less complex or have less business value, making it less important to virtualize them in depth, while other might be the opposite. Having limited resources, a good approach will be to focus your virtualization efforts on the interfaces where testing might be more complex. Set up your own set of factors to decide on the virtualization depth necessity. Some of the factors are frequency of use, complexity, accessibility and business value.

Consider creating good and reliable virtual services for subsystems. You may have a subsystem that will be difficult to access during the test creation and runs. These subsystems are usually vulnerable and contain sensitive information. If you come across one of these, remember that this is a prime candidate for mocking. It will help you decouple that system during test creation or even development.

Think of reusing virtual services

Earlier, we said that virtual services are often discarded after being in use for some time. Think of scenarios, in which the virtual service will be useful. These can be the cases when the people involved needed the service, because the live API is inaccessible or cannot be used. Just an example from our community member: they used their virtual service as a selling tool. The sales engineers installed ReadyAPI and run the virtual service on their computers, showed the mock as an example of a real service and then demonstrated a web page that looked like a prospect’s web site consuming the virtual service as an example of the value the company delivers. This approach was extremely successful and non-expensive, since the service was made by the QA engineers earlier and the web page was created in a few hours.

So, let’s repeat, the virtual services can be reused by different employees: by you, by your team, by QA, development or sales engineers, by partners or even by your customers.

Consider hosting in the cloud

You might be in a situation, when you do not have local hardware for hosting your virtual service, that is, you might have no place, where your virtual service can run and be available for several people. You might have a machine in a company, but have no access to it, or employees, who need the service, may have no access to that machine, and so on.

In this case, consider hosting the virtual service in a cloud like Amazon EC2. This will not be free of charge, but, in many cases, prices are surprisingly affordable. In general, the cloud services are very easy to set up and use, and do not require special technical knowledge, so it is a very viable option.

To run a virtual service on a cloud machine, you can install VirtServer there. For more information, see Running Virtual Services.

How Do I Start?

See our tutorials and sample projects.

Why Creating Virtual Services?