Still, we can at least strive toward the ideal, and new DevOps teams and agile workflows can accelerate the process, helping to make production journeys as smooth as possible by improving communication, building multiple software components concurrently, and implementing frequent automated testing. There is one thing, however, that can stymie even the best DevOps team, and that’s waiting on dependent components. Simple unit tests can be performed on bits of code or single system components in isolation, but reliably testing code and system integration can prove impossible if your test environment is missing crucial dependencies. And this is where service virtualization can speed things up dramatically.
With service virtualization, your DevOps teams can use virtual services instead of production services, enabling frequent and comprehensive testing even when key components are missing from your system architecture. By emulating the behavior of essential components that will be present in a final production environment, service virtualization allows complex applications to undergo integration testing much earlier in the development process, removing key bottlenecks that would otherwise delay production and time-to-market for an application under test (AUT). For the development of most enterprise applications, which rely on a mixed array of system components working together in harmony, service virtualization “fills in the gaps” of missing system components by simulating their responses to show how the various components interact. It is especially useful in the development of complex cloud-, API-, and SOA-based systems, as well as at any point in a production cycle where important hardware and software components aren’t readily available for testing purposes.
More and more companies are using service virtualization to improve productivity, reduce testing costs, and deploy higher-quality software in a shorter timeframe. In addition to emulating major software applications, third-party services, and even whole backend systems, the virtual assets can also be reliably shared and used by your entire production team, facilitating more efficient parallel development practices. By quickly and easily removing dependency constraints across your organization through virtualization, you can gain a competitive advantage over other companies still waiting in the linear-development limbo.
Virtualize Your Services with ReadyAPI
Why Use Service Virtualization?
Traditionally, testing teams have had to wait for nearly completed applications to be deployed before proper functional, integration, and performance testing could begin. Distinct project teams might produce different components of a system or application, one piece at a time, and then assemble them into a single working product before allowing the testers to have their way with it. It’s logical, it’s linear, and it’s slow.
Focusing on testing a nearly finished software application—with all of its components nicely integrated behind a functional user interface—will obviously remain an essential step in any development cycle, but in these days of rapid (and continuous) development cycles, it often isn’t practical to wait that long before testing to see how various software components communicate with each other. Testing needs to happen alongside development from the start, and this is especially true in the production of heterogeneous systems involving multiple layers of interdependent components, third-party apps, and APIs. The fact is, by the time any modern application has a testable UI, that’s usually just the icing on top of a very complex, multi-tiered cake.
Continuing with that delectable metaphor for a moment, we could say that the use of service virtualization makes it possible to test the overall flavor of our cake much earlier in the process, while we’re still adding ingredients to the batter—and even if the batter is lacking major components like eggs, perhaps, or flour. With our complete cake recipe in hand, knowing exactly which ingredients we need, our virtual ingredients can temporarily stand in for any genuinely missing ingredients as we proceed. This allows our agile app bakery to easily spot any odd combinations of flavors we might accidentally introduce into the cake batter, step by step, before it ever goes into the oven and long before it’s iced.
In other words, service virtualization is ideal for those test-driven development (TDD) teams who want to expedite their production schedule by focusing their bug hunt at the API layer, where major problems down the line are often first introduced into system interfaces, rather than having to wait to test a more complete production-ready app. Using service virtualization, developers can validate integrations earlier than would otherwise be possible. And considering that the user experience of an application is wholly a function of the sum of its parts, it makes sense to ensure that those parts are working well as they’re created, rather than waiting for a finished application. Service virtualization can be useful at any point in the development of an application, from assisting with small manual unit tests to enabling automated performance tests of an integrated system.
Unless your company has sufficient resources to provide your developers and testers with every actual component required by a production system, using virtual services throughout the development cycle can save a lot of time and money. Any software development team can benefit from service virtualization, especially when it isn’t practical to repeatedly test against dependent third-party components, such as Salesforce, Oracle, or PayPal. By virtualizing the behavior of a CRM, ERP, or payment gateway in your system architecture—with simulated data and software responses—your development efforts will be able to proceed freely and you’ll be able to conduct tests as often as desired, paving the way to smooth user acceptance tests down the line once the actual third-party components are deployed.
Mocking vs Service Virtualization
When software engineers, testers, and system administrators first hear about service virtualization, they may confuse it with server virtualization or virtual machines. But service virtualization doesn’t emulate servers themselves, in all of their complexity, as much as it emulates a key point at which a server might interact with your application. Service virtualization only simulates particular behaviors of software that your application needs to test against, whether those behaviors are the result of interactions with mainframes, databases, cloud servers, mobile devices, payment gateways, ESPs, CRMs, ERPs, and so on. Since the goal is simply to expedite development, there’s no need to virtualize any function, API call, or service that you don’t require for your test environment.
Likewise, service virtualization is often confused with mocking and the creation of simulation stubs, but they’re not the same thing (and neither are mocks and stubs, for that matter). Mocks and stubs are fake software components that are used by developers to imitate real software components for testing purposes, which initially sounds a lot like service virtualization. However, one of the biggest distinctions between mocking services and virtual services is that mocking functions tend to be very context-specific, simulating a specific behavioral response to fulfill a certain development need at a certain time (i.e., injecting a missing dependency in order to bypass its absence, or temporarily test its presence, perhaps in isolation from the rest of the application under test). Virtual services, on the other hand, can be deployed throughout the entire production cycle, consistently delivering—for all development intents and testing purposes—the same behavior and functionality for any developer or tester who wants to use them, at any time. Thus, once they’re created and exist as part of a project-wide test environment, virtual components eliminate the need for individual developers to write and rewrite their own mocks and stubs, saving time and effort for all concerned.
Another important distinction is that with mocking, individual classes can be simulated, while service virtualization enables the behavior of entire network backend services to be simulated. And as far as an application is concerned, those responses issued by virtual services are as good as the real thing. But when using mocks, their shelf-life is limited by their believability; one function’s use of a simulated payment gateway’s behavior, for instance, may be invalidated by another function’s attempt to use the same payment-gateway mock. From a testing perspective this means that, generally speaking, mocking is best suited for unit tests and service virtualization is better for integration and performance tests. Ideally, a well-rounded engineering team would judiciously employ both mocking and service virtualization in its quality assurance arsenal.
Understanding Service Virtualization
So what kinds of development situations are best suited to service virtualization? And how, exactly, does it work?
As service-oriented architectures become increasingly common, there are no shortage of third-party software components available that would love for you to use them in your latest application. These third-party apps can take care of everything from managing your customer database to performing quick credit checks, from handling your email subscriptions to processing the inventory and orders in your online store. Most applications today—even simple websites—make extensive use of third-party software, and these self-contained services save developers from having to build similar native functionality in-house, from scratch. But ensuring that your application communicates smoothly with third-party apps can present plenty of problems of its own, especially when your application is dependent on those third-party components, which may not yet be integrated with your code or easily available for testing purposes. Developer Marcia Kaufman of the Hurwitz and Associates consulting firm offers an example of such a situation, in which service virtualization would come in very handy:
Consider, for example, the scenario of an online retailer with multiple suppliers. The retailer has created a new mobile application for customers. This application uses a credit check service provided by a third-party vendor. The team can’t test without this dependent component, but it is not available for testing. Without service virtualization, the software development team has some difficult choices to make and none of the options are good. If the development team proceeds without doing the necessary testing, they may introduce errors that are much harder and more costly to fix later on. If the team waits until the third-party service is available, developer productivity will decline and the team may miss production deadlines. In addition, if the third-party service becomes available it can get pretty expensive to test application performance at high usage levels since the service costs money each time it is executed.
By simply virtualizing the credit-check service in question, Kaufman’s hypothetical use case is easily resolved. At least, it’s easy to explain. But how does one go about actually creating such a virtual service? Service virtualization software typically uses one of two potential methods to generate virtual components.
The first is by starting with a standard service description that outlines the parameters your components must follow, and then using your virtualization software to generate appropriate code (such as XML, .Net, or Java) to simulate the behavior of the components you need. This requires some work to set up and refine, as most automated testing tools do, but each completed virtual component usually only needs to be created once in order to be repeatedly and continuously used in your development and testing environment.
The second method is potentially (but not always) simpler, involving using service virtualization software to create traffic recordings of actual system interactions and API calls between your application and the dependent components in need of virtualization. By recording real system traffic, service virtualization tools can generate simulated “responses” between applications, dependent components, and even the backend servers they depend on. But no matter how your own virtualization software learns and generates such exchanges, it is this ability to perfectly simulate key system behaviors that makes service virtualization such an incredible tool.
The Future of Service Virtualization
Naturally, the biggest reason for using service virtualization is to save time and money by catching development errors early in production, as well as bypassing the need to stand up an expensive test lab. Popular service virtualization software applications can run on common, affordable hardware, and the virtual testing environments you establish can be easily modified and recycled to suit different needs over time. Whether or not your organization needs to invest in a service virtualization solution, however, will depend on your own cost-benefit analysis. But if quality assurance is an important component of both your business model and software development life cycle, you may want to give it some serious thought. Virtualizing your API itself can also be a huge cost saver.
In this ever-accelerating era of web-based services and mobile applications, where an end-user’s personal perception of your offering can count for more than anything else, it’s important to have developers, testers, sysadmins, and business stakeholders united in a shared understanding of the importance of software quality. But it’s equally important for teams to be able to work together as rapidly and expediently as possible. As various agile workflow methodologies become the norm, the skillful use of a tool like service virtualization—which encourages teams to engage in parallel development tasks, and “bakes in” testing from day one—will be a deciding factor in setting a production team apart from equally fast-paced competition. From here on out, the teams that best employ virtual services may gain the upper hand.
Written by: John Paul Mueller
Further Resources