Service Virtualization

This is the second in a series of Visual Connections blogs focused on exploring continuous testing.
Our goal is to share industry best practices, help you reduce costs and testing efforts, and increase your return on investment (ROI) potential.

Service Virtualization

By:
Fred Deese | Visual Connections President & CEO
Bas Dijkstra | Visual Connections Testing Engineer & Test Automation Expert

In response to the increasing demand for delivering high-quality software at speed, many organizations have adopted -or are in the process of adopting- a Continuous Delivery strategy. A vital part of this strategy is the effective leverage of test automation to have insight into current application quality at all times, a process known as Continuous Testing.

Mainly, these Continuous Testing efforts are targeted towards writing and executing functional automated tests, anywhere from the unit test level all the way towards full-stack integration and end-to-end tests. However, to get a complete overview of the current state of application quality, only performing functional test automation is not enough.

This three-part series introduces three of the many other techniques that you can leverage as part of your Continuous Testing approach to get a better and more complete indication of application quality at all times during the software development lifecycle.

Service Virtualization

Speaking about testing the internal business logic of individual services, this too has become more complex with the increased interconnectivity of applications. Provisioning test environments and creating the correct state for performing integration and end-to-end tests, both from a functional perspective as well as, for example, for performance testing purposes, is becoming increasingly complex because of the number of dependencies a given application relies on.

These dependencies can hinder teams and organizations looking to move towards Continuous Testing in various ways, such as:

Dependencies can be under development themselves, rendering them unavailable for integration testing
It can be hard to set up the right state or the right test data required for specific test cases in dependencies
Dependencies can be available for integration testing only at certain days and times (e.g., mainframe systems that are shared by many teams)
Dependencies and especially third-party Software as a Service (SaaS) dependencies can charge access fees for their usage

All of the above issues pose limitations on the freedom that teams have in incorporating dependencies in their integration and end-to-end testing efforts.

One of the approaches that can help mitigate these limitations is service virtualization (https://en.wikipedia.org/wiki/Service_virtualization). This approach revolves around the creation of simulations (sometimes also called ‘virtual assets’) that simulate the behavior of dependencies that are required for integration testing, yet are hard to access or control.

It is important to stress that service virtualization is centered around simulating the behavior of dependencies. Since dependencies typically integrate and interact with systems under test through standardized communication protocols (e.g., HTTP, JMS or MQ) and messages formats (e.g., XML or JSON), the way that these dependencies are implemented is irrelevant. For example, when simulating a dependency that is built in Java and that communicates via a RESTful API with its connected components, there is no need to also build the simulation in Java, as long as the transport protocols and message formats (and contents) are equal (or at least similar) to the actual dependency.

Another pitfall that teams and organizations fall into when adopting service virtualization is that they try and simulate every single use case that the actual dependency supports, with the reason that they might need it at some point in time. By doing so, though, they are essentially rebuilding the entire application that they are trying to simulate. As a rule of thumb, with service virtualization, it’s better to err on the side of simplicity and straightforwardness and try to simulate just enough to support your integration and end-to-end testing efforts. When done well, adopting service virtualization can have three tangible benefits for your testing efforts, and, by proxy, for your entire software development lifecycle:

Test earlier. When you have a simulation in place for a dependency that’s under development, there’s less, or even no waiting time until that dependency is available for integration purposes.
Test more. One of the key benefits of service virtualization is that erroneous behavior is just as easy to simulate as ‘happy path’ behavior. Consider, for example, the case where a team is building an online store, and they want to test continuously that their store can handle payment provider outages and error responses properly. This is extremely difficult, or even downright impossible, to achieve by using a test environment of an actual payment provider (often a third-party system). With service virtualization, it’s easy to create a simulation that, for example, when given specific input such as a designated product or customer ID, replies with a timeout or unexpected content in a response message.
Test more often. Actual dependencies, especially those developed and maintained by a third party, are almost never available for testing at all times. Simulations (virtual assets), however, especially when distributed in a container-based format such as Docker images, can be deployed and used on-demand and thrown away or recreated afterward. This means that creating the entire test environment can even be done as part of the Continuous Delivery pipeline, which makes the overall testing and deployment process extremely flexible and scalable.

As a final note on service virtualization, it should be said that there is just no substitute for testing against ‘the real thing.’ However, the harder it is to use ‘the real thing,’ and the worse it suits your Continuous Testing efforts, the more benefits service virtualization can potentially bring to your team.

Blog 2 in this Series
See other blogs in this Series
Consumer Driven Contract Testing

Fred Deese

After nearly a decade of providing advanced web and application development services to both the private and public sector, Fred Deese co-founded Visual Connections, an information technology consulting firm, in 2007. As Chief Executive Officer of the company, Fred is focused on new business development, overall company positioning, and client relationships.

Since the company's inception, he has held project management positions on many prominent and complex commercial and government IT projects, personally providing the services that have made Visual Connections widely recognized by its customers for its innovative technologies and quality work. See Full Bio Here

Bas Dijkstra

I help teams and organizations improve their testing efforts through smart application of tools.

In my 13+ years in the testing profession I have successfully designed and implemented test automation solutions for a wide variety of clients. I’m currently mostly active as a trainer, teaching people and teams how to make their first or their next move in the world of test automation.

I love to share and expand my knowledge of the test automation field by delivering talks, workshops and training courses, both at conferences as well as on-site with my clients.

You can contact me on LinkedIn via https://www.linkedin.com/in/basdijkstra or through my blog OnTestAutomation.