In my last blog post about service virtualization, I discussed testing using a virtual response to simulate application behavior that was still evolving or not yet available. Today I’m addressing the next question – what if there are additional requirements or conditions that cannot be created with the normal application because the behavior of the backend system requires some abnormal configurations?
Service virtualization allows us to approach this challenge by not only giving us unconstrained access to backend systems and technology, but by allowing us to take control of the responses provided by those components. Typically, service virtualization is used to simulate happy path behavior of dependent components in an environment, or to fill a gap when a component is missing, but there’s another side to this point. We could flip that workflow upside down and use service virtualization to simulate abnormal behavior for an existing component.
Abnormal Behavior Simulation
What is abnormal behavior simulation? Most simply, it refers to providing negative responses from services in a predictable way to validate for, or guard against, specific application behavior. To illustrate this concept, we might consider a situation in which a developer wants to bulletproof their application against upstream outages. This sounds like an important task for every developer, but realistically, doing this is normally impossible.
Imagine the developer building a shopping cart application that leverages PayPal and wanting to build in some functionality that handles an outage from PayPal. Perhaps they want to make sure that the end user does not lose their progress if PayPal were to suddenly go offline or send a negative response. Testing this condition would be a challenge in a real environment.
How would a developer do this without virtualization? Picture a phone call to PayPal: “Could you make your servers timeout for a few hours today?” Not only is this not going to be a nice conversation, but even if in the off-chance they did introduce the negative behavior, it would affect your entire development environment. Anyone who wanted to test against the PayPal API that day would suffer.
This is where service virtualization is so powerful. Since the developer is in control of the virtual service, it will be easy for them to configure this abnormal behavior. They could create a Virtual PayPal interface at their own private endpoint by referencing the WSDL or Swagger documentation provided by PayPal or any 3rd party service contract. They would then go into the virtual service and set it to “500 Internal Server Error.” This would allow the developer to see what would happen to their code under these conditions. Taking this a bit further, they could simulate a “200 OK” but respond with malformed JSON or even set the service to respond with a considerable delay just to see what happens. The possibilities are endless.
This type of on-demand abnormal testing is invaluable. It allows developers to massage their code while controlling all types of abnormal response behavior. This speeds up the process of validation and makes better application code overall. But that’s not where it stops. There are additional, typically unthought-of areas where simulating abnormal service behavior can be quite a benefit for development organizations, and that is the idea of Defect Virtualization.
Defect Virtualization
Think of Defect Virtualization as a “negative replay.” What you are doing is you are creating an abnormal environment for an application to “live in.” Think about a crash test dummy – you’re not going to set a crash test dummy into a car that’s just going to drive down the road under normal conditions. Chances are, the environment that that dummy has been placed in is specially-configured to provide him with a pretty bad day.
This is the same in defect virtualization. Simulating negative conditions that could occur externally will force an application into exposing some kind of unexpected behavior. This can be quite powerful because you can use that simulated environment to replay the behavior for QA or development teams. The team could take this simulation and see, firsthand, what the issue is.
This would replay the negative behavior for them consistently and in the process of fixing the application they could “replay” the scenario in the negative environment, to make sure that the new code has resolved the issue. In the video below, I’ll show how to test against abnormal conditions, on-demand. I am also going to uncover a defect in my application and show how through abnormal testing I can reliably replay the conditions that expose it. I’ll do this within the new free Community Edition of Parasoft Virtualize.
About the author:
Chris Colosimo is a service virtualization and API testing subject matter expert focusing on Continuous testing at speed. He is a Sr. Technical Consultant with Parasoft, whose primary role is Enterprise strategy and deployment of the Continuous Testing Platform across the major organizations. Chris is obsessed with SDLC acceleration through automation. He works with developers and testers to discover constraints, evolve processes, and facilitate the change management required to adopt agile and DevOps principals throughout the organization.