10 Reasons Why Your Developers Should Stop Stubbing and Mocking and Start Using Service Virtualization ALL THE TIME!
Stubs and mocks may work great for individual-unit testing. But what happens when a system is too complicated to mock or stub? Or you need to test against a third-party API or service? How will QA test the code if the dependencies are unavailable? How can the code be tested for performance using real-world conditions earlier in the dev cycle?
So here we are in 2017. It’s time to make those resolution lists, put new plans into action, and if you’re a football fan … enjoy PLAYOFF time! In addition to being the year that the Dallas Cowboys may make it to the Super Bowl for the first time in 21 years, 2017 will mark the 10-year anniversary of iTKO (now CA) introducing service virtualization to the market. I’m not trying to age myself here, but I recall spending the first 30 minutes of customer meetings in the early days explaining the differences between hardware virtualization and service virtualization. At least that is one conversation I don’t have to have anymore!
Although service virtualization has become a widely understood capability in the software application development space (there are even books on the topic—my favorite is Service Virtualization: Reality Is Overrated), where and how to best leverage service virtualization remain questions for many clients. I find myself spending a fair amount of time talking with customers about how they can leverage service virtualization across the SDLC instead of having development build mocks and stubs and having QA leverage service virtualization later in the life cycle.
With the NFL playoffs in full swing, I started thinking: How do the best football teams train so that they can consistently perform at the top of their game? Okay, it’s a given that it starts with each individual on the team being in top shape and working hard in the off-season and in the film room. But as many underdogs have proven over the years (the Rams in ’02, the Giants in ’08, and, of course, the Jets in ’69 come to mind), just having a bunch of Pro Bowlers isn’t always enough to finish on top. In addition to individual talent, it takes collaboration, a shared vision, and a well-thought-out set of plays that the team consistently executes.
A one-handed diving catch for a touchdown is an exceptional INDIVIDUAL play, but it does not form the foundation of consistent plays that a team executes week after week, improving and tweaking as they go, eventually leading them to the Super Bowl. Similarly, companies winning in the application economy have a great set of plays that they are consistently improving and continuously executing. No matter how great your developers are at stubbing and mocking, these are still just individual efforts that can’t be used as consistent plays for your team to leverage every day, week, or month to accelerate delivery and bring game-winning innovation to market faster. It’s not that you can’t build a mock or a stub to continue your development efforts, but WHY do it when better, faster tools exist that produce a higher-quality output? If you’re using service virtualization anywhere in your SDLC, you should be using it (almost) EVERYWHERE in your SDLC
It’s not that you can’t build a mock or a stub to continue your development efforts, but WHY do it when better, faster tools exist that produce a higher-quality output? If you’re using service virtualization anywhere in your SDLC, you should be using it (almost) EVERYWHERE in your SDLC.
One of the original uses for CA Service Virtualization was to enable parallel development—to let developers create new functionality for their applications to drive new revenue or competitive differentiation rather than wasting time coding mocks or stubs. Not only is developing a mock or stub a time suck, the bigger issue is that the benefit of that asset is minimal and fleeting. Service virtualization should be used at dev time, just as it should be used during the various test phases. And the asset created at dev time should be used at test time. It can be invoked as part of a continuous testing or integration process that leads to the consistent acceleration of applications.
“The alternative was good old mocking and stubbing. At the end, we ended up with CA Service Virtualization, due to its enterprise nature. It played a major role to have a centralized place for simulations where we can maintain, reuse, and extend them.” — IT Professional, Medium Enterprise Financial Services Company, Source: TechValidate ID: E4A-285-107
Here are just a few benefits you will receive from using a platform like CA Service Virtualization and Application Test that you won’t receive from mocks and stubs:
- Reuse of virtual services and collaboration across development and testing teams rather than every application team having to create their own mocks and stubs
- Multiple ways to automatically create virtual services—service recording, request response pairs, data-driven virtual services, and swagger
- Complete testing of application business logic
- Magic strings and dates rather than static information
- Better realism and quantity of performance tests
- Rich tools for editing and managing virtual services that cut down on maintenance time and development costs
- The enabling of continuous testing by automating the provisioning of virtual services for testing
- The ability to virtualize and desensitize test data in early-stage development and test efforts
- The ability to simulate transactions and connections that mocks and stubs can’t: mainframes, databases, and third-party services
- Access to more systems and services by virtualizing things that are impossible, or very time consuming, to mock or stub: complex systems, third-party APIs, and non-web services
That is why companies serious about faster delivery of higher-quality applications are adopting service virtualization across the SDLC. For many companies, service virtualization is no longer a technology decision but a business one.
A great example of this is how SunTrust Bank used CA Service Virtualization to virtualize its data, services, and third-party services, and to prep test environments. The bank saw several concrete results:
- 53% of delayed requirements now tested on time
- 18,505 defects were found prior to production, with a defect rate of less than 1% (the target had been a defect rate lower than 4%)
- 22% cost savings was achieved on managed services compared with 2014, including $1.97 million savings due to automation and $900k in direct savings
- 73,302 work hours were saved by tools and automation
- All “can’t fail” initiatives were met
The benefits of service virtualization that is initiated during development and leveraged throughout the life cycle are massive—and we’ve been proving that for 10 years. Any benefit gained from a mock or stub is temporary at best. We have been using the term “continuous testing” for a while now at CA, and it makes sense when you consider how companies should be leveraging service virtualization.
I may not be able to predict who will win this year’s Super Bowl, but I can predict with 100% confidence that adopting service virtualization will massively improve your ability to get better, quality applications to market faster!