Support for negative test cases - making sure the application behaves gracefully when a dependent system returns an error - is one of the more valuable and unique attributes of Service Virtualization.

It is imperative that the system under test reacts appropriately in the presence of external failures, but creating the external failures can be very difficult. How do you get a dependent system to report that it timed out trying to service a request? Do you physically pull network cables? That, of course, would disable the system for all testers – not just those testing the timeout scenario.

Many schemes have been created to support negative test cases but, in the end, the shear difficulty of creating “failure on demand” means negative testing is often limited in scope and poorly covered.

Service Virtualization makes it easy to introduce “failure on demand.” I built virtual services for a major Australian bank where 80% of the test cases involved the failure of, and retries against, a dependent system. We were able to return distinct failure codes mapped to specific account numbers on the request. Using stateful interactions, we could control how many times the same request would fail before returning success on a retry.

It’s a common sin of programmers to catch runtime exceptions and “drop them on the floor” – returning a success response to the caller and hiding the stack trace in a far off log file. When negative testing isn’t performed, these sorts of workflow failures will first occur in production – when real customers and your company’s reputation are on the line.

Create test cases for failure scenarios, and create virtual services that support these test cases. You’ll catch critical error handling problems before your code ever gets shipped.

More Best Practices from Mike Gavaghan:

• Antipatterns - Reinventing the World
• The Cart Goes After the Horse
• Test the Correct System
• Create the Service that Meets Your Team's Needs
• Don’t Wait for the Artificial Intelligence to Kick in
• Selecting Random Responses is a Bad Idea
• Avoid Too Much Data
• How to Choose the Right People to Train
• The Consumer of the Service Should Build the Virtual Service

Mike Gavaghan is an experienced solutions architect who has been implementing virtual systems for many years. As a reminder, best practices are only a guide. Although these solutions have been used in the past, they still carry a certain degree of risk and should only be applied after carefully ruling out conventional solutions.