Service Virtualization
In the best of all possible worlds, software engineering, testing, and operations teams always work together in perfect synchrony, delivering high-quality products to market on schedule, under budget, and completely error-free. But in this world, that’s never going to happen. The sheer challenge of creating today’s increasingly complex applications, which generally consist of multiple interdependent components, guarantees that every software development life cycle is going to be in for a frequently bumpy ride.
What is Service Virtualization?
Time-to-market, development costs and application quality are top priorities for organisations developing software. Constraints remain a fundamental challenge to timely, cost-efficient, high quality software development and delivery.
One area of focus for many development teams is mocking and/or stubbing of application code to reduce dependencies on components of the application environment.
Three options traditionally utilized for solving this constraint problem are in-house, developer-written code, proprietary tools, or open source tools including Mockito. However, there is a much more elegant solution — Service Virtualization.
For those new to Service Virtualization, it is a method of capturing and simulating the behaviour of constrained or unavailable systems.
When to use Service Virtualization
The primary use-case for Service Virtualization is pretty clear — the application you are developing and/or testing is dependent on some other service. It does not matter whether this other service is an in-house micro-service being developed simultaneously with your component or a 3rd party system that has been running for years, but what is important is that your application or module depends on it and therefore it is also a dependency on your testing flows. Since this is not always practical, the obvious choice is to virtualize these services (dependencies) and isolate your development and tests from real environments that may be difficult or not practical to provide for development and testing. There are also other aspects that demonstrate the added value of Service Virtualization.
First of all, let’s assess the difference between object mocking and Service Virtualization. Object mocking, represented by tools and frameworks like Mockito. It is a well-known and heavily adopted concept and it is best utilized when doing unit testing, where it is very handy to be able to mock particular objects from the object model your application is using. With the right objects mocked, the unit test can focus on what has to be tested and not how to set various objects to the right state just in order to be able to perform particular test scenario.
However, the nature of unit tests and object mocks isolates these techniques from proper and robust integration testing — i.e. I need to test how the full stack of my application behaves based on the response from a dependent service. For example, in the case of dependencies based on HTTP APIs I may want to know what happens if particular HTTP responses are returned (including various HTTP statuses as well as response bodies and headers) and not just to isolate this by mocked objects on a higher level of abstraction.
This is where Service Virtualization (SV) comes in. With an SV solution you can create virtual endpoints that simulates the behaviour of the real service. Services on which your application depends on may be an unstable system that is not accessible all the time and that could potentially be a bottleneck in your testing process. With service virtualization you always have dependency available.
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. 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 behavioural response to fulfil 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 behaviour 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 behaviour 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 behaviour, 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.
Getting started with Service Virtualization for Developers
There are multiple options for tools to help successfully adopt Service Virtualization, it is just up to the preference of the particular developers and the way how their development processes are driven.
First of all, the experience closest to developers’ nature are in-code virtualization tools like CodeSV where developers could define virtual services directly in the code using Java. This is the smoothest way for developers to adopt the concept of Service Virtualization, as they can define the virtual service in code using fluent API and leveraging all benefits of IDE like code-completion.
Another easy to adopt option is Service Virtualization: Community Edition (SV CE). It a desktop application that allows you to define and host virtual services based on HTTP/HTTPS and also to record traffic to real service and create the virtual service based on the recorder traffic. Using SV CE, developers could spin-up individual virtual endpoint that may be used for integration testing within the team.
The full-featured, enterprise-ready solution is Service Virtualization — besides HTTP/HTTPS it can virtualize variety of protocols and standards like JMS, Kafka, JDBC, MQ, CICS. As the SV CE it is able to record traffic of all of the supported protocols that speeds up the process of creation of virtual services for complex services. To make sure Service Virtualization supports current CI/CD needs and best practices, it can be deployed via Docker containers and it also provides its own Jenkins plugin supporting its own Jenkins Pipeline commands. From the point of developers, SV Eclipse IDE plug-in helps in adoption of Service Virtualization in development as developers can easily spin up and control virtual services directly from their IDE. In addition to that, SVasCode Java library that helps to operate enterprise Service Virtualization through Java code and also RESTful HTTP API provided by the tool.
Service Virtualization offers compelling advantages to development teams that help them to take continuous testing to the next level. Check out these YouTube videos to get started with the free Service Virtualization for Developers Toolkit.
