API Testing & Monitoring

API Testing Series – Service Virtualization and its Problems


In our second post of this series, we discussed how developers currently address the issue of testing with dependent services using simple stubbing and the issues that can lead to. The first attempt to address these was to use a concept called ‘Service Virtualization’ (SV). This article discusses what exactly ‘Service Virtualization’ is, how it can help but also the issues that are still there when used.

In order to explain SV and how it works, we will take a relatively straightforward real-world card payment example. Nets is a standard payment hub available extensively in the Nordic region. A standard interaction would look like the following:

The process is relatively straightforward and works as follows:

  1. A ‘Register’ request is made to register the transaction and get a transaction ID.
  2. A validation the holder of the credit card will take place either via redirect or based on a POS terminal.
  3. A ‘Query’ request can be made to get the status of the transaction at any time.
  4. An ‘Auth’ request is then made to reserve the amount.
  5. Finally a ‘Capture’ request is issued to draw the reserved payment.

This is how it would look from a technical perspective:

In order to create an SV implementation of this, it’s necessary to introduce a proxy between the service calls and the real environment as illustrated below:

This will result in the request and responses being recorded in traffic logs for future use. These recordings can then be used to simulate the back office without a real environment being available as illustrated below:

While this solves some of the issues of simulating the interaction with dependent services, it also introduces a number of other issues:

  • This requires access to real environments to create the recording.
  • There are potential data governance issues accessing data in real environments.
  • It is very difficult to create failure tests without impacting on other users as the real service must be broken to achieve this.
  • Recordings can be replayed out of sequence so the correct process is not enforced.
  • All interactions are 100% tied to the recorded data.
  • Recordings go out of date and re-recording can be time consuming to set up and manage.

Service Virtualization is useful for regression testing but is not not suitable for the complex testing requirements in an agile and digital world. Our next article in the series will discuss how the next generation of SV, sandboxes that simulate the dependent services, can resolve these issues.

John Power

John Power

CEO of Ostia Solutions
John has over 35 years’ experience working with enterprise IT systems in various roles including development, design and architecture. He has used this experience to create a suite of products to address lack of access to complex test systems which is a major bottleneck in the roll out of new products and the on boarding of external customers in large enterprise organizations. The result of this is Ostia’s Portus EVS technology which enables the creation of clever, simulated test systems and sandboxes on demand. These sandboxes facilitate the modelling and testing of new standards for Open Banking and PSD2, and implementation of new technologies such as Blockchain.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture