CodeSVby CA Technologies

When mocking and stubbing just aren’t enough

The Problem

These days, software developers are required to deliver software as soon as possible and with high quality. It means that there is constant pressure to create tests for code which has dependencies with other services. And here lies the problem; how to deliver code with high code coverage when dependent services are not finished?  This is especially challenging in cases where development of dependent services is done in parallel.  Another common use case is when the dependent service is a 3rd party service over which the development team has little control or even sometimes when there is cost associated with consuming dependent services. We can mock them, but is it enough to ensure a sufficient level of quality? With mocks you can configure what will be returned, but what if you’d like to test a real call on a service which is not finished yet?

Let’s say you’d like to create a test for your new application which needs to use retrieved information from service A (which is not yet complete or is 3rd party service). You know how the response should look but they are not accessible when you need them.

This is the exact point where you can start thinking about service virtualization (SV). With a virtualized service, you can create a call on the service and configure a specific response that you expect to be returned. The call creation is the main difference between mocking and actual service virtualizing. In other words, with a virtual service, you can cover more than just the inner mechanism of your code because the virtualized service can actually cover a real HTTP call.

The CodeSV solution

You can achieve that virtualization with our free tool, CodeSV. It offers a custom API for creating customized HTTP virtual services quickly and easily.

Our solution is based on dynamic request interception at the JVM level, which means that you do not have to tweak your code under test to change it to call a virtual service, instead the virtual service is completely transparent to the code being tested. This solution makes it possible to create a real call on the service which returns a pre-defined response via API.  Let’s take a look at a code example below:

Basic virtual service definition with JUnit @Rule

import static com.ca.svcode.protocols.http.fluent.HttpFluentInterface.*;

import static org.junit.Assert.*;



import com.ca.codesv.engine.junit4.VirtualServerRule;

import org.junit.*;



public class ExampleTest {



  @Rule

  public VirtualServerRule vs = new VirtualServerRule();



  @Test

  public void exampleTest() {

    forGet("http://www.example.com/time").doReturn(

        okMessage()

            .withJsonBody("{\"timestamp\":1498838896}")

    );



    // Now you can create a request to http://www.example.com/time

  }

}

The main item to take note of here is the easy response definition created by the forGet(String Uri method.  This is where we configured the OK message with a simple JSON payload for the service which should be running on the path defined by the Uri variable.

It’s that easy! This is where the core value of CodeSV lies – a simple, powerful and easy to use library.

More complex problems? We can handle it!

Let’s say that we already have a service which works and we’d like to create a test which covers more requests.  The problem is that several of them are not implemented yet. Now it’s time for our matchers!

You can virtualize a service using matching criteria like headers and queries (for example).

All others calls which are not matched are sent to a real non-virtualized service. This is the value in using the matchers; it provides an easy way to support virtualization for already implemented services. For one endpoint, you can define what should be virtualized and what should use a non-virtualized service. In other words, you can create a very specific virtualization configuration. More about our matchers, and how they work, can be found on our Docs.

Do you want to virtualize a service with Basic Authorization? Use our matchesBasicAuthorization method and that’s it. Take a look here for additional details.

We also support the HTTPs protocol so you can virtualize secured communication. It’s a piece of cake when you use our API. Take a look at a code example and description here.

We already implement CodeSV. How can we leverage the benefits of CodeSV when also using the CA Service Virtualization solution?

CodeSV is a member of our SV family so you can share resources and definitions across the products.  Request-Response pairs are one example of this.

The virtual services you have defined in CodeSV can be exported as Request-Response (RR) pairs and then used in our CA Service Virtualization solution. Simply use our codesv.export=DIRECTORY_FOR_EXPORT runtime variable to enable and define the save location for exporting these virtual service definitions. These can then be imported into CA Service Virtualization.

In conclusion

In this post, I’ve described to you the following highlights:

  • CodeSV provides you simple and powerful library for virtualization;
  • CodeSV is a new way how to save valuable time during development;
  • It is a completely free and lightweight library!
  • HTTP virtual services are completely transparent to an application under test;
  • Our API provides a solution for creating and running HTTP virtual service definitions directly in your tests.

A few other CodeSV features and functionalities which you might find interesting:

  • Virtualized HTTP Get and Post methods (include basic authorization, different formats, encodings and more);
  • Lambda expression support;
  • Matching mechanism;
  • Complex assertions;
  • HTTPs support;
  • Virtual service definition export (RR Pairs);
  • Magic String and Magic dates (dynamic variables);
  • Post call verification.

If you’d like to check all our functionalities with examples, please visit our Docs!