How Service Virtualization defeats the most common API performance testing problems

shutterstock_294412070

 

The web as we know it today — populated by user-friendly eCommerce and service sites like eBay, Flickr, Facebook and Amazon — couldn’t exist if not for the humble web API.

APIs, or Application Programming Interfaces, make it possible for technology, business and politics to be merged seamlessly into a world of self-service goodness. Developers can collaborate and create new functionality for existing services by designing their app to interact with a known quantity. APIs are why Google and Apple could grow into two of the world’s largest companies.

Sergey Brin and Jeff Bezos should pen a love song to Roy Thomas Fielding for coming up with the idea of APIs way back in 2000.

All of which is not to say that APIs don’t pose problems of their own for developers. As we’ve written here before, APIs were something of a miraculous leap forward when they emerged only a few years ago, but code writers — and, importantly, their employers who foot the bills — soon realized they were also a constraint in development. How?

Because the burgeoning companies whose servers developers wanted to tap into and network with imposed expensive query limits and restrictions. Testing against such limits required one of three unpleasant actions:  1. Raise the project budget. 2. Slow the project waaaaay down. 3. Test less.

Fortunately, there’s a solution: Service Virtualization.

By virtualizing the API — effectively, creating a copy of the API that behaves just like the real thing — developers using Service Virtualization are freed to minimize the expense of API calls while maximizing their testing opportunities.

Actually, access to a virtualized API is actually better than the real thing for the simple reason that you can test all kinds of scenarios — varying levels of functionality, performance and maintenance levels — with a virtualized service that you never could with an API. You can make the virtualized API behave any way you want.

That capability allows you to defeat all of the most common API testing problems:

Management by hand: Today’s development tools, with integrated SV capabilities, can help automate your workflow, freeing up developers to develop — not write tests. That’s less expensive and results in a more robust product.

API surprises: Too often, enterprises have restricted themselves to only testing their own APIs. With today’s heavy reliance on other peoples’ web services, failing to model for others’ API irregularities is a massive oversight. Unless you account for all APIs, and all potential behaviors of those APIs, you don’t really know how your app will work in the real world. It’s not enough to leave that testing up to whomever owns the API. To your customers, the blame game won’t matter. If your app fails to operate because of someone else’s API, the customer blames YOU.

The guessing game: It might be a fun exercise when the carnival barker tries to guesstimate your weight at the county fair, but guessing in development can get very expensive. With a virtualized API, you don’t have to make random response time assertions. You can test all possible response times to ensure fewer errors — and fewer disappointed customers. And, you can set up tests to verify all independent services and endpoints — not each in a vacuum, but all together. That is, you can test the API that fetches inventory data, the shopping cart API, and so on, simultaneously, as the customer will use them.

Dismissing a minority of errors: Too often, if an app tests 99-plus percent successful, we chalk that up to a victory and move ahead without working to understand the extreme minority of errors. Big mistake. In real life, that rare error could indicate a systemic problem. It’s best to keep testing until the error is fully understood. Service Virtualization frees you from call limits, so you can keep testing, and testing, and testing until your app is completely debugged.