A Brief Introduction to Service Virtualization
Software development and testing occurs in conjunction with other activities. Most of the code that is written and tested depends on several resources that are often beyond the reach and control of a developer or a tester.
For example, say you are developing an e-commerce mobile app that lets you browse items and make a payment in this scenario, the mobile app likely integrates with several systems, including databases and web-services (APIs). These integrations allow you to get items, make the payment, and ultimately place the order. Many of these resources are in your control – but many others are not, because they’re owned by other teams. Such resources are called third-party dependencies.
A typical list of third-party dependencies for this example may look like the following:
| Resource |
Owner |
Availability |
| Database |
Yourself |
Always Available
|
|
User Profile API
|
CRM team |
Still Under Development |
| Inventory API |
ERP Team |
Only in Production
|
|
Payment API
|
Payment Gateway |
Needs a Credit Card |
| Ordering API |
Order Management Team |
Available, but with Rate Limits
|
As you can see in the above table, not all the dependencies are under your control. Often while developing code you will reach a point when you must use these third-party dependencies and interact with them. One example might involve getting data for a customer profile screen. If these dependencies are not ready and responsive, you will have to stop working on the code that call them.
Often, to work around this, developers will write functions or methods that return a hard-coded API response. This is not ideal, as the hard-coded values are valid for just one scenario and not reusable, this also encourages bad code writing practices. Similarly, a tester testing functionality that depends on other unavailable resources will be forced to skip testing until that resource is available, adversely impacting test coverage.
Unavailable dependencies create issues for developers and testers as they limit the amount of development and testing that can be done. Without full availability of dependent resources and services, all possible use cases do not get covered.
This results in limited unit testing and many of the test cases do not get executed at all. Often these dependencies cause bottlenecks. Teams have to pause their work because they’ve come to a point where they absolutely need the actual third part services. Without them, it’s not possible to get any work done at all.
Mocking Is A Workaround, Not A Solution
Mocking provides a way to emulate the missing resource, especially APIs, while testing or developing a software. Mocks are very basic setups that are created on code or on tools that can mimic, for example, a few API calls. This allows the development and testing teams to do a very basic level of testing using these emulated calls.
Generally, mocks are created by development teams in code, and run for their own development and testing. Mock creation for users who are non-developers is difficult: testers often use open source tools for creating mocks – and if they don’t have strong coding skills, they’ll find this very hard to do. There are not many ‘easy to use’ open-source tools available for mocking.
A good example of a tool that allows testers to create mocks is the open source version of SoapUI. However, as it is an all-purpose API testing tool (rather than one focused solely on mocking or virtualization), it doesn’t make it easy for testers to scale and adapt mocks to multiple testing scenarios.
It’s important to understand that any test that is being conducted must be easily scalable to multiple scenarios. The reason of this is that, as your testing becomes more complex, the scenarios become more complicated.
For example, initially testing a phone number API might be as simple as fetching a phone number and asserting (a concept used in testing, where you assert a response parameter against a predefined value) the phone number format. But as the business case scenario becomes complex, you may have to test against different variations of phone numbers —they might be from other countries, or contain special characters.
To test these scenarios, you need to have API mocks that are capable of responding with different permutations of phone numbers, and unless your mocking solution supports easy and scalable creation of mocks, you’ll find it hard for you to configure it for all these permutations.
Reasons Why Mocking Is Not Scalable
1. Mocking does not support quick creation of scenarios for testing at a moment’s notice.
Mocking can be very ‘personal’, as it’s hard for developers or testers who have spent a lot of time creating these mocks to share their work with their peers.
2. Mocking is stateless.
This means that it’s very hard for a tester to setup common information (parameters) that can be used across all the mocked responses. For example, if you are testing a banking transaction, then you may want to take the name of the customer and the bank account number across all mocked API responses.
Unless your mocking tool supports this, it’s very hard to set this information up and ensure that it gets passed through all the test cases. You will end up spending hours just to set up the wiring mechanisms to do this.
3. Mocking is heavily reliant on code
Its usability depends heavily on the skill of the developer or tester creating the mock. Most of the mocking tools available on the market right now are based on scripting and coding hence it becomes very difficult for a tester or a person who lacks coding skills to think about developing a mock for their testing purposes.
4. Most of the testers and developers working with APIs spend most of their time working on the front end.
Therefore, their knowledge of API technology and specifications is limited. A modern-day API is built on protocols like XML and JSON, also using specifications like SOAP and Swagger, and unless you have knowledge about these protocols and specifications it would be hard for you to build a mock around them.
Because a usable, functional mock requires creating detailed requests and responses, it requires the ability to understand JSON and XML, and to parse values in and out of them. It would be hard to create a sophisticated mock without the support of a tool that does the heavy lifting around working with these protocols and specifications.
You Need Service Virtualization
Service virtualization has recently become popular along with up-and-coming processes like Agile and DevOps. It allows sophisticated and ‘real life’ emulation of a service that is either unavailable or hard to access.
Recently in our ‘State of Testing’ survey we found that 72% of the testers are testing against APIs which are owned inside the organization. So, most probably you are testing against a service that belongs to a team next door and due to issues around communication with the teams, accessibility to artifacts and unfinished work you are not able to use these services for your own development and testing.
Service virtualization plays an important role here by providing ‘real life’ simulations of these services for your testing and development purposes. This reduces dependencies and friction between teams and improves collaboration in the long run.
In the survey 28% of the respondents said that they test or develop against external or third party services like Google maps. These services are often expensive or the rate at which the service can be utilized is throttled (controlled) by third-parties, and is therefore inadequate for day to day testing and development purposes.
To help visualize what this looks like, use the following example:
Say you are developing an e-commerce application and you are integrating with a payment gateway. In this case, it would be difficult to repeatedly test a credit card’s transaction functionality without making a payment with your credit card. However, if you could accurately emulate the payment gateway service and test or develop off it, you could test your e-commerce application as many times you wanted – without any restrictions or a fear of being charged.
In addition to this, there are many other reasons for unavailability of third party services. A few of them are captured below:
- Still under development
- Undergoing maintenance/update
- Difficult to set-up for testing or development
- Owned by third parties
- Too costly to use (paid APIs like Google Maps)
- Restricted access (due to geography or security restrictions)
One important thing to remember is that a third-party service does not always have to be an API. A service could be a network service, a telecommunication service, or a database. A service virtualization solution could help you emulate any of the services that your software development or testing depends upon.
It’s always useful to list all the services that your software or testing process depends on and build a back-up plan catering to the ‘uncertainty of availability’ for each. Once you have a plan for each of the dependencies, then every time these dependencies become un-available you can put that plan in motion. With a virtualization solution in place, you would be able to quickly spin up virtual services and continue your development and testing even though a service is unavailable.
With increasing competition and the advent of Agile and DevOps, the pressure has increased on teams to deliver faster and more frequently, unavailable services often creates bottlenecks that cause teams to stop working.
This result in unnecessary delays in the delivery of the application to the market, and in many cases, dilutes any productivity effects that adoption of best practices like Agile and DevOps have had on the overall delivery time lines.
Unlike mocking, which requires manual configuration and scripting, service virtualization enables quick and easy creation of virtual services. Services could be created by providing API specifications or recording service traffic with just a few clicks. In ReadyAPI developers and testers can use a built-in UI recorded to access websites, isolate the backend API calls and create virtual services out of them. 
With one virtual response created, it’s very easy for developers and testers to clone and customize it for different use cases.
For even more flexibility and scenario coverage, virtual responses can be linked to data elements from a data source like Excel or a column in a database like MySQL and Oracle. Beyond this, service virtualization also enables emulation of network conditions like limited bandwidth, as well as hardware conditions like small capacity servers, that are hosting the service, being virtualized.
These features enable testers and developers to create realistic environments for their development and testing. With very few clicks, they can record an API response, link the elements in the response to a set of scenarios in the database, and quickly use them to develop and test – even when the actual services are not available.
ReadyAPI also enables quick switching between the virtual and the actual service so if the developer or tester needs to hit the actual API, they could do so the just a flip of the switch.
For these reasons, service virtualization solutions enable teams to move faster, work continuously, and deliver on time, without being delayed due to bottlenecks caused by other teams and services. The net result of using service virtualization is that teams have better control over their testing and development environments and they can quickly customize these environments and adapt them to their testing needs as desired.
Read Next: