Software Development is an iterative process. With each iteration the software evolves, and as functionality gets added, the dependency of the software on other components grows. Often this dependency is a result of integrations with other systems. These integrations are often through APIs controlled by other people and teams. Now, unless the person owning these APIs sits next to you there will be a time when you are left waiting because the API is unavailable, under development, too expensive to invoke or not just created yet. This frequently causes unnecessary pauses in the development and testing process as developers wait for the API to be restored or made available.
API mocking is one way to work around these issues. Mocking allows you to configure a few responses, install these on a server, and then develop or test against it. The issue with mocking is that you have to custom create each response and take pains to deploy it before you can even start using it. For a development and test environment which integrates with tens or even hundreds of microservices, doing this for each becomes a formidable challenge.
There are benefits of mocking but only when there are only a few API interactions to mock. For each additional API interaction, the effort doesn’t decrease as each service interaction needs to be built by hand, by coding or by uploading a response and configuring it – in other words, it’s not scalable. Thus, developers need to have a deep understanding of the API request response structure. They need to know so much about the third party APIs that it defeats the purpose of having a decoupled architecture and microservices.
Switch gears from mocking to virtualization
API virtualization encompasses the ability of easily creating and using rich simulations of the actual service without having to go through configuration pains and uploading requests and responses. This is a very different concept from mocking, there is no time needed to set up, no need to know the API interactions and no installing of mocks through complicated procedures.
Below are some other points that distinguish sophisticated virtualization from mocking. Virtualization provides you with the ability to do all of the following in a script-less and configuration-less environment:
- Record and discover API interactions from multiple APIs through browsers and gateways
- Immediately generate and run a simulated service from the recorded interactions
- Enhance the captured interactions with custom data from a data source
- Configure multiple interactions for a request and have the ability to decide, manually or through logic, which response to send
- Seamlessly switch between actual and virtual services, with just a click
- Share the created virtual services with the team
Creating a hurricane with virtualization
Dependencies often hold up development and testing. Sometimes, not everything goes as planned in a sprint and there are times when a developer is left waiting for access to an API which is still being worked on by others. Virtualization can be of help here as it allows quick configuration of expected and unexpected API interactions. Unexpected interactions may include errors. Developers can even generate scenarios that occur rarely on the real service, like “406 Not Acceptable.”
Now let’s see a scenario where the developer needs to test an alert screen on an Android app that calls a weather service. The developer wishes to test a set of weather alert scenarios; one way is to pray to weather gods to cause a hurricane for a few moments so that the functionality can be tested. The other (and much more constructive) way is to set up a virtual service with one API interaction and then copy that interaction over five times and edit the responses representing varying hurricane conditions with different wind speeds and atmospheric pressures. This setup can now be used by the developer to test the screen for multiple scenarios quickly and see how it looks exactly in variations of storm conditions. If the developer wishes, he or she can add an error scenario on the fly to test how the screen will respond to a 406 error in just a few clicks. Weather may be out of your control, but virtualization is not.
Switching your way to faster development
Being able to easily sandbox your APIs and use them with a few clicks is valuable, but frequently you will need to access the actual service. Developers may cycle through the simulated scenarios and then for a few cases want to hit the actual service. The ability to seamlessly switch between environments is key, and should be available in any sophisticated virtualization solution. Developers do not want to waste time and effort just configuring property files and restarting services, just to point the environment to the real service. This reduces the incentive to do through testing and frankly takes away the joys of software development. In the hurricane example above, after finishing the tests on the storm conditions the developer might want to quickly test the alert screen on the real service to see if his recent changes still work there. In a good virtual service solution, the developer will be able to do this with just a click. It’s just a matter of switching environment, which should be hassle free.
Generating realistic scenarios with virtualization
Sophisticated virtualization should allow developers and testers to not just generate scenarios but also put them under different environmental conditions—more specifically, network conditions, congestion, bandwidth and server capacity. A virtual service should allow the developer to control the speed of response, simulate bad network conditions and test the software thoroughly in such exceptional conditions.
Again referring back to the weather app in the earlier sections, a virtualization solution should be able to generate appropriate emulations of a network congestion through bandwidth simulations to see if the users will still get the critical weather alerts even if the networks are not performing well. What if the hurricane takes a data center offline and the service is running just over a single instance hosted in a different availability zone? The virtualization tool should allow simulation of server performance in order to test such scenarios on the weather app.
Virtualization is a very strong concept that can help a team get to the end goal of quality and reliable software faster. To fully understand the value this can add to your software development process, it’s critical to first understand the time and effort your team spend in getting the integration pieces together for a successful delivery of your application. Then, iteratively thinking how you can shave off time and costs by virtualizing pieces of it. The idea of providing a context here with mocking is to give you a sense that if your developers use mocking then you already have an existing runway for your virtualization strategy to take off.
A good virtualization solution should be easy to get started with for individual developers and testers, provide capabilities to fully simulate the actual service, and provide hassle free switching between virtual and the actual environment. ServiceV Pro is a virtualization solution from SmartBear that provides all these capabilities and much more. The tool is a part of the ReadyAPI suite of applications and allows you to very quick capture and create a virtual service from a single user interface. Developers can get up and running with ServiceV Pro in minutes, create sophisticated virtual services and start coding against them. Testers can easily integrate their functional and load tests with the virtual service creation and management.