What is Service Virtualization, and How Can It Benefit Developers?
What is Service Virtualization?
Time-to-market, development costs and application quality are top priorities for organizations 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.
Last year when I spent three days at our Continuous Testing booth at AWS re:Invent. I had a chance to speak with many developers that were interested in agile testing solutions. Surprisingly, all of them knew the challenges of continuous testing that they or their teams face, but besides two rare exceptions, nobody knew about the concept of Service Virtualization, as a solution for their challenges. And that’s really a pity as Service Virtualization could make our life much easier, and testing much better.
For those new to Service Virtualization, it is a method of capturing and simulating the behavior of constrained or unavailable systems. The litmus test of a Virtual Service is that the system consuming the service cannot tell it is not the real system.
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 behavior 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.
Service Virtualization- For Full Stack Integration Testing
Here are some real life examples where Service Virtualization can help your development team:
A dependency on your component is being developed right now by another team in your organization. Your work is done, it is coded according the API spec you received, but you have to wait until something else is ready. With SV you can begin testing against a virtual version of the dependency.
Your test code is behind firewall and you cannot access production dependencies unless the code is in some higher environment or production - which again forces you to do either a trade-offs in your testing, or spend efforts to fix it somehow.
You have to pay for every hit and volume of the performed operations against the dependency of your application - which obviously you need in production, but not during your load testing that could generate significant amount of requests to the dependent service.
But it is not only about having the dependency available. With Service Virtualization it is you have the entire behavior of the dependency under your control.
You may return responses that contains test data that is very hard or impossible to load to the real service.
You may return responses that represent various failure scenarios that may be very hard to reproduce using the real service - as the service is not yours, you cannot break it at will just to be able to test whether your app could recover from such a state.
With an SV solution you can also have the response time under your control, which is very useful for performance testing of your application. This is especially useful when you want to test the performance of your app, and not your app’s dependencies. In other words, you are interested in whether the latest code change really improved the performance and in order to validate that, you don’t want your tests to be affected by network glitches or unpredictable performance of the dependency.
In addition to this, you may stretch your app to figure out how it behaves if the dependency returns responses in very slow pace - could your app recover from network timeouts gracefully?
Shift Left Testing with Service Virtualization
Service Virtualization is an essential concept for successful Shift Left Testing. This means testing earlier in the development lifecycle to save costs through identifying issues earlier in the life cycle.
In order to help developers to really implement the shift-left paradigm, they have to have the right tools that will enable them to perform various types of testing as early as possible during development. This is typically the issue that leads to various trade-offs, low coverage, or robustness of the test.
One typical example is how to perform integration or performance testing if the test scenario depends on something that is not under the development team’s control (for the reasons we stated above). Service Virtualization helps to resolve this common roadblock and lets developers focus on the tests themselves and not about how to get access to various environments or 3rd party services. They don’t need to force real services to behave the way they need in order to perform specific test scenarios.
Also, artifacts defined by developers for their tests - the definitions of the virtual services - could be used later in the life cycle by different teams who may be responsible for regression testing or turning everything in automated and reproducible CI/CD flows.
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.