Service virting is practice of creating a virtual environment (API) that works similarly to the real API you are creating. Virting is also called isolation, simulation or virtualization. This virtual environment (virtual service, or virt) imitates the real API: it defines operations that clients of your real API will call, receives client requests and simulates responses. You use virts when you cannot use the real service.
You can 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 virting 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 waits for the other to finish. This makes the financial argument for virting particularly strong.
You can create tests for unavailable resources. Service virting 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 ServiceV on a remote machine, or you can export the virt as a Web Application aRchive file (WAR) and deploy it and run it on any Java server like Tomcat.
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 virt, 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 virts 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 virt 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.
You may have to duplicate your work. After you created and used a virt for some time, in many cases, you will finally replace it with a real API. The value of a virt is only based on how well you can use the virt during its life time. For that reason, it is a good idea to balance the efforts you put into the virt. 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 virt to the real API faster, in ServiceV, you can configure your virt to redirect (route) client requests to your real API. This will make the transition easier and seamless.
Some virts 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 virt will run. However, this is the same problem that you have with running real web services. So, to run your virts, 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. If you deploy your virt as a WAR file, the computer needs to have just a servlet container like Tomcat.
The virt is a representation of a real web service, and it is possible that it is not accurate. Most often, it will be an ideal of the web service you are virting: it will not have any service specifics and a few bugs. Engineers create virts in order to have a stable test environment, and quite often they remove a lot of complexities of a live environment from the virt. Make sure that all stakeholders understand that the actual environment will introduce complexities. The functional tests you create in SoapUI 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 virt and to move the virt into a live environment. Do not do this! Virting is for virting and nothing else. It means that a virt will not provide real functionality, even though it looks like it might. Manage expectations. Even though the virt works fine, it does not mean that the real service will.
Despite the drawbacks described above, virting 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 virts.
Use a very simple rule of thumb: your virt 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 virt 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 virt 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.
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 virt 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 virting, and get a commitment for the scope from your team.
Once you have formed an idea of what your virt 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 virt, things will run smoother, and you will not miss the important features and behavior.
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 virting efforts on the interfaces where testing might be more complex. Set up your own set of factors to decide on the virting depth necessity. Some of the factors are frequency of use, complexity, accessibility and business value.
Consider creating good and reliable virts 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 virting. It will help you decouple that system during test creation or even development.
Earlier, we said that virtual services are often discarded after being in use for some time. Think of scenarios, in which the virt will be useful. These can be the cases when the people involved needed the virt, because the live API is inaccessible or cannot be used. Just an example from our community member: they used their virt as a selling tool. The sales engineers installed ServiceV and run the virt 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 virt as an example of the value the company delivers. This approach was extremely successful and non-expensive, since the virt 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.
You might be in a situation, when you do not have local hardware for hosting your virt, that is, you might have no place, where your virt 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 virt, may have no access to that machine, and so on.
In this case, consider hosting the virt 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.
With ServiceV, you can export your virtual service into a file of the Web Application aRchive (WAR) format. This makes it possible to deploy and run the virt in any Java server environment. It will run the virt on a standalone basis without ReadyAPI or VirtServer installed. This is a very simple way of testing your network and making your virt available for your team. See Deploying Virt In WAR Format.
See our tutorials and sample projects.