Service Virtualization and Contract Based Testing

By Pallavi Darbhamulla | September 6, 2018

In the new world of micro services, as the number of services goes up, it gets harder to deploy multiple services on your development box. Also as the number of micro services increase in an environment, it makes no sense to start up multiple services to be able to test the actual integration between various services either manually or via automated tests. In this regard, the concepts of service virtualization and consumer driven contract testing become important to adopt as part of one’s development workflow. There is a fine line between the two and sometimes those lines can seem blurred. I will make an attempt to explain the distinction and overlap between the two in this blog post.

Service Virtualization

When there are multiple teams involved and each team is dependent on multiple micro services from other teams that may or may not be in usable state, it is best to try to use “emulated” versions of those services aka “virtual services”. Thus the part each team requires to use, can be virtualized and used in their individual testing.

e.g. If a team A depends on another team’s (B) service to allow login to a particular system, then that specific login functionality can be virtualized and team A can simply run the virtual login service rather than having to always hit the real login service from team B. This helps team A to be independent of the availability of team B’s login service and allows team B to independently develop features on the login service without worrying about other teams being dependent on it.

A virtual service is created by recording functionality against the original service so that when a function is called against the virtual service, it responds with actual values that would be returned by the original service. There are multiple tools for service virtualization and depending upon your exact situation, you can select the right tool.

We have played with Hoverfly and have found it to be very useful in service virtualization. Recording is possible both via curl or via a Java client.

Consumer Driven Contracts:

This represents a contract between the consumer of the API and the API provider. In the example above, if the login service from team B has a defined contract that team A is expecting, then a test written against that contract should always pass. When team B creates the login service, it is expected that a test will be written by them to test their own service. This would really be known as a provider test to test that the login service behaves as expected. When team A, the consumer uses the login service, they can write a test against the endpoint to see that the login service works as they expect it to. This test would be the consumer test. A consumer test should pass against the main service and the virtual service.

To aid in collaboration between various teams using the login service, all consumer tests should be run against the main development branch of login service to ensure contracts are up held. As team B continues to work on the login service, if they change or modify behavior that affects the contract, it is imperative that they run the consumer test against the login service to identify that they either purposefully or inadvertently broke the contract. Thus, Consumer driven testing should be a part of your CI/CD pipeline.

If there is a change in contract, the following should happen:

  1. send out a communication with the change to the various consumers,

  2. a new version of the virtual service should be created and deployed and

  3. all consumer tests should be updated to honor the new contract.

Only when all consumer driven tests pass, should a build be considered safe to deploy.

There are various options for consumer driven tests as well. The main one that is language agnostic is Pact. If you are a Spring based development shop, even Spring Cloud Contracts are another option to handle contract based testing. Recently there was an update indicating that Spring Cloud Contract has now support for non JVM languages as well.


  1. 2/05/19 - move from WordPress to Hugo

  2. 2/15/19 - updated all formatting with move to full hugo site

comments powered by Disqus