How I Use Service Virtualization in DevOps

What is service virtualization? Well, it is a hot topic for one! But do you know what it really means — and how to leverage it? Find out in this blog! 

What You Should Know About Service Virtualization

Service Virtualization is a method of capturing and simulating the behavior of constrained or unavailable systems. The litmus test of Virtualized Services is that the system consuming the service cannot tell it is not the real system.

The top priorities for organizations developing software are time-to-market, development costs, and application quality. I have found that environment constraints remain a fundamental challenge to timely, cost-efficient, high quality software development and delivery. 

One area development teams should focus on 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. Service virtualization is also a great way to resolve this constraint problem, but is usually less well-known.

Ways I Use Service Virtualization

My primary use case for Service Virtualization is when the application you are developing and/or testing is dependent on some other service.

Whether this other service is third-party or in-house, your application or module depends on it and is a dependency on your testing flows.

Since this is not always practical, the obvious choice is to virtualize these services (dependencies) and isolate your dev and testing efforts from real environments to avoid impractical or overly difficult situations.

What to Know About Service Virtualization vs. Object Mocking

Service virtualization is often compared to object mocking. Object mocking is a well-known and heavily adopted concept in the world of virtual services. Mocks are best utilized when doing unit testing, where it is very handy to be able to mock particular objects from the object model that your application is using.

With the right objects mocked, the unit test can focus on what needs to be tested instead of setting up various objects properly for different test scenarios. 

However, the nature of unit tests and object mocks isolates these techniques from proper and robust integration testing. For example, in the case of dependencies based on HTTP APIs, you may want to know what happens if particular HTTP responses are returned. This scenario is much more complex than merely isolating mocked objects on a higher level of abstraction.

This is where service virtualization (SV) comes in. With a service virtualization solution, I can create virtual endpoints that simulate the behavior of the real service.

Services on which my application depends may be an unstable system that is not accessible all the time and that could potentially be a bottleneck in the testing process. With service virtualization, I always have these dependencies available.

How I Used Service Virtualization for Full-Stack Integration Testing

Here are some real-life examples of when service virtualization can be of value to your development team:

• Testing dependencies during development. Let us consider a situation where another team is in the middle of developing a dependency on your component. My work may be done according to the API spec you received, but I have to wait until something else is ready. With service virtualization, I can begin testing against a virtual version of the dependency. 

• Testing code behind a firewall. In this case, I cannot access production dependencies unless the code is in some higher environment or production. This scenario will either force me to do trade-offs in my testing, or spend time fixing this issue. 

• Paying for volume after load testing. I have to pay for every hit and volume of the performed operations against the dependency of my application. But I do not need it during load testing, which can generate a significant number of requests to the dependent service.

But it is not only about having the dependency available. With service virtualization, I have the entire behavior of the dependency under my control. 

• I may return responses that contain test data that is very hard or impossible to load to the real service. 

• I may return responses that represent various failure scenarios that may be very hard to reproduce using the real service - as the service is not mine, I cannot break it at will just to be able to test whether my app could recover from such a state. 

• With service virtualization, I can also have the response time under my control, which is very useful for performance testing my application. This is especially useful when I want to test the performance of my app and not my app’s dependencies. In other words, I am interested in whether the latest code change really improved the performance and in order to validate that, I don’t want my tests to be affected by network glitches or unpredictable performance of the dependency.

In addition, I can use service virtualization to stretch my app to figure out how it behaves if the dependency returns responses slowly. 

How I Used Service Virtualization for Shift-Left Testing

Service Virtualization is an essential concept for successful shift-left testing. This means testing earlier in the development lifecycle to save costs by identifying issues earlier in the life cycle. 

In order to truly implement the shift-left paradigm, I 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 I stated above).

Service virtualization helps resolve this common roadblock and lets developers focus on the tests themselves and not about how to get access to various environments or third-party services. I 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.

Service Virtualization Tools I Considered

I assessed multiple options for tools to help successfully adopt service virtualization. When comparing service virtualization tools, I often compare my personal preferences with how my development processes are driven.

CodeSV

First, the experience closest to developers’ nature is in-code virtualization tools like CodeSV where developers could define virtual services directly in the code using Java. This is the smoothest way for me to adopt the concept of service virtualization, as I can define the virtual service in code using fluent API and leveraging all benefits of IDE like code completion.

Service Virtualization: Community Edition (SV CE)

Another easy to adopt option is Service Virtualization: Community Edition (SV CE). It is a desktop application that allows me 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, I could spin up individual virtual endpoints that may be used for integration testing within the team.

Legacy Service Virtualization Solutions

Another powerful option I considered is found in traditional, commercial service virtualization solutions. By simulating the behavior, data, and performance of dependent systems, these enterprise service virtualization solutions can speed up testing and reduce the costs associated with access to live systems.  

But traditional service virtualization also comes with an array of challenges that makes it less suitable for organizations looking to shift left. Not only are these solutions very costly to own, but they are also only available on-prem and less user-friendly.

Why You Should Use BlazeMeter Service Virtualization 

BlazeMeter Service Virtualization (also known as BlazeMeter Mock Services) offers me a streamlined approach to virtual services that addresses the challenges posed by legacy service virtualization solutions. Service Virtualization provides me a cloud-based, automated, maintainable, and deployable virtual services option that helps me test at earlier stages of application development.  

BlazeMeter offers me the best of both worlds when it comes to service virtualization: the benefits of traditional service virtualization implementations without the complexity. To better understand the difference and determine which is right for your testing needs, check out this comparison on Service Virtualization vs. Mock Services.

Watch the webinar below to take a closer look at BlazeMeter Service Virtualization and see how it works:

Bottom Line

Service virtualization has played a vital role in the software development and testing ecosystem for over 20 years.

But enterprises need a lightweight virtual services solution that is simpler to use and more cost-effective, while fully integrating with the rest of your testing. Organizations need to eliminate the bottlenecks that come with traditional options and shift service virtualization to the left.  

I recommend trying BlazeMeter Service Virtualization today to see how you can bring service virtualization into the era of agile. 

START TESTING NOW