Testing When the API Isn’t Ready

With the complexity of today’s applications, it’s easy to end up in a situation where all of the pieces of your code aren’t ready at the same time. As a developer, you might be waiting for a 3rd party API to get updated, a partner organization to finish their code, or other teams in your organization to have a component ready to start testing against. This can be a drag on your organization’s entire release schedule, as testing is backed up waiting for all the pieces to be finished.

Service Virtualization was designed with this in mind. It provides development and testing teams with unrestrained access to complete test environments by simulating the dependent components that you would otherwise be missing or waiting for.

The Blame Game

In an Agile environment, developers can work simultaneously all over the codebase on interconnected system components. Each developer needs to access other developer’s components in order to complete his or her own tasks. Often we encounter a situation in which one developer needs responses from another developer’s component or API early in the project – so early, sometimes, that the other developer has not even created the code that is being called. This means that one, or both developers, will be stuck until both pieces of code are finished. In software, we call this a deadlock.

I face this challenge frequently when I’m writing code. My team might be working on a web application that is customer-facing, and each sprint includes a new set of user stories to implement functionality based on data I get from a REST API. And on an almost daily basis I am stuck and cannot work on my application code because one of the APIs I depend on is not in a working state. This can come from a variety of reasons, but it usually has to do with one of my colleagues introducing a bug somewhere in their code as they are working on the API.

The big problem with this is that I’m on a deadline and my manager is looking to me to have this code in by the end of the sprint. And so, what I usually have to do is walk over to my colleague’s desk and dive through their code with them to help resolve the challenge they’re facing. (This is great… we’re collaborating developers… what a rare event!) But unfortunately what actually ends up happening is that I spend the majority of my time debugging their issues to unblock myself. This means they finish their code on time, while I do not.

Waiting for access to dependent functionality throttles agility. How am I supposed to work under these conditions? The answer is to simulate. I can use Service Virtualization to break free from these deadlocks and rapidly build a virtual asset that simulates practically any anticipated behavior.

Using Service Virtualization

I will use Parasoft Virtualize to show you how to do this (which you can now use for free with the new Community Edition). You can create the simulation without having to do any scripting – either in the GUI or from a definition file like WSDL. For instance, in the early stages of API development, the WSDL or schema might not be available and the developer may only have a sample response available. With Virtualize, this is more than enough to get started.  I simply grab the response object and paste it into a responder. I can then flip a switch and the tool will create a schema on the fly.  This is very useful, because I don’t need to worry about sending the correct payload, and as the data changes, Virtualize will ensure that the payload structure remains consistent every time a response is sent.  This makes simulating the response very easy.  The endpoint is set up automatically and always available. I only need to focus on what data I want the new response to send.  With Virtualize, you can also visually model various message formats such as XML, JSON, and various legacy, financial, healthcare, and other domain-specific formats.

There are major advantages to working this way with a simulated response, the most important of which is time.  A simple service response can be set up in a matter of minutes, versus days of waiting for the real service to be available. This allows me to start working immediately, making responses to develop against and instantly seeing the impact on their new code.  This helps me code smarter and faster because conditions that would normally be unpredictable can be tested out immediately and function can be adjusted in real time.

This is exactly what I do to get myself out of this waiting cycle. When one of the backend APIs goes down, I use service virtualization to simulate the response. I can put in whatever payload I want, and I know that it’s accurate because I’ve used a definition. I’m also confident that it will supply me with the correct data because I’m in control. Using this technology allows me to hit my deadlines.