Agile software development aims at teams to deliver value faster. Idea is to deliver quality and predictability with aptitude to respond to change and deliver in iterations. In these circumstances we often may have to deal with bottlenecks when dependent APIs are unavailable or unreliable. Service Virtualization allows us to build and test applications faster by eliminating these dependencies.
Why?
It addresses how to shift left efficiently in an iterative development methodology by providing a way out from:
- Unavailable Services (External systems)
- Dependent Services (under development)
- Unavailable Data (Need to generate test data to test the scenario under construction)
- Inconsistent Environment (No environment to deploy complete ecosystem)
Service Virtualization allows us to create a simulated version of a service helping to develop system interactions independently in an isolated environment. Simply playback an expected response and see how the system works. Configure complex test conditions using stubbed responses which otherwise would be near impossible to test in a live environment due to several dependent factors.
Most of the time we are unable to test an edge case scenario due to unavailability of data. Service Virtualization allows us to generate and stub responses which would help emulate such edge case scenarios. Moreover the onus is a stable and reliable contract generated to test such scenarios consistently every release.
What to virtualize?
- The service is costly to use.
- The service is available only for limited timeframes.
- The service is needed by multiple teams.
- The service is being developed.
If the answers to these questions is a Yes, then such services should be considered for Virtualization.
Can I virtualize every system interaction?
Yes. However, be cautious while doing so! If the virtualization is at the services layer, sure, but if you are having to execute scripted and compiled code outside of your application then consider not to.
Avoid keeping counts in a virtual service. Let's consider a banking domain use case where you want to validate that a user’s account activity screen gets updated when you transfer money between two accounts. What you can simulate easily is a user's experience of transfer money, or validate account activity screen displays the required field as per requirement in isolation. However you will need extra code to simulate that the amount which was transferred is getting reflected in the user’s account activity. This involves managing states of the services which does transfer money and the one which is used to get account details information. In case of stubs, the account details service stub will always send the response with a balance when the response was recorded. You can update the value in the response based on the state captured from transfer money, but that means you are writing additional code to update which should not be the intention of service virtualization.
Can you do this? Yes. But I would not recommend managing states between services. Break down the use case and validate the intent of the service and the behaviour in isolation.
Mocks vs Virtual Service:
Although mocks and virtual service are used interchangeably, there are differences between the two. Both serve the same purpose but in different forms and phases.
Benefits:
- Reduced dependency on internal teams or third parties.
- Isolate behaviors in a shorter time frame
- Eliminate the need to build infrastructure for every feature/scrum team per release
- Enabling CI by enabling continuous test data and continuous test environments
- Run realistic and quantifiable Performance tests
Challenges:
Tools:
Examples of few tools available for Service Virtualization in the market:
Tool Comparisons: https://trafficparrot.com/Service_virtualization_and_stubbing_tools_comparison.html
https://www.softwaretestinghelp.com/service-virtualization-tools/
Top comments (0)