Testing the API Backend of your Mobile Solution

Ole Lensmar

January 18, 2013

If you’re building mobile applications today, chances are high that they are getting their data or logic from a bunch of backend Web APIs, either crafted by your team or provided by a 3rd party. Not surprisingly, over the last two to three years, APIs have turned out to be an extremely potent catalyst for both applications and businesses because they give you immense flexibility in targeting new devices and platforms.

In this three-part series, I’ll take a look at API quality and how SmartBear tools can be put to work to ensure the quality of the APIs that form the backbone of your mobile business – at each the development, testing and deployment phases.

Background

A mobile application (be it native, hybrid or web) will talk to its backend APIs via standard protocols, most commonly based on HTTP and REST principles using JSON or XML as data format. These APIs may either be your own or from any number of 3^rd parties (for example Twitter or Google Maps), which can be integrated by calling them directly from your application, or indirectly via your API backend:

indirect API integration

There are several advantages to indirect integration, including:

Your API backend can aggregate and choose which data to return to the mobile client, lowering bandwidth requirements
You can handle changes to the 3^rd party API centrally, instead of having to update the mobile application
You can centralize and hide handling of errors and unexpected behavior in your 3^rd party APIs
You can replace a 3^rd party API provider with another without disrupting the client (provided of course that the new API provides equivalent functionality)
You can handle authentication and API keys for 3^rd party APIs from the backend – hiding this logic from the client

Direct integration has some advantages too:

Lower latency because the response from the 3^rd party doesn’t have to be routed through an intermediate
Possibility to utilize client-libraries available for many 3^rd party API providers
Easier to utilize single-sign-on authentication for 3^rd party services

I’m sure both lists could be expanded – the choice boils down to your requirements and resources.

The API backend itself can of course be anything from a simple node.js or grails application to a complex SOA based on J2EE or .NET. Underlying data could be handled in relational databases, NoSQL stores or external REST APIs, and the backend could be hosted on local servers or in virtualized cloud environment.

However you craft your solution, you will need to tackle testing and quality aspects of your APIs – let’s look into this in a little more detail.

How does API Testing fit into the Quality Lifecycle

We all know that quality is something that needs to be infused into your project way before you start coding (right?) – requirements need to be reviewed, UI mockups need to be tried out, backlogs need to groomed and prioritized, architectures need to be assessed (to some extent at least).

If you’re using Agile techniques, you’ll be doing this iteratively during the evolution of your application – if you’re using Waterfall techniques, you might be doing more of this up-front. In either case, your planned APIs definitely deserve some attention during the inception phase also; choice of technology, data format(s), security, authentication, management, etc.

Unit testing and code reviews are popular quality efforts during actual coding that will increase the quality of your code – but to make sure you’ve put all the pieces together in the right way you need to test at the API level also. You can see this API testing as an integration test for your classes/objects/scripts/data-stores used to implement the API.

1. Functional testing

Initially your API testing will focus on functionality to make sure that your APIs return the expected responses for both expected and unexpected input. You might use a keyword-driven testing approach to allow testers to define test harnesses at a higher level, or you might use data-driven testing to test large sets of input and expected output data. Functionally test your API’s with SoapUI NG Pro.

2. Performance testing

Performance needs to be tested and ensured; preferably you design your functional tests so they can be reused as load-tests to make sure that functionality works as expected even with multiple concurrent clients, and that performance is in line with your performance requirements (which you reviewed during the inception phase – right?). LoadUI NG Pro, is a complete solution for performance and load testing your APIs.

3. Security testing

Security testing is an extremely important activity as well – APIs often give direct access to the data and logic that form the core value of your business; you have to make sure your APIs aren’t vulnerable to common attacks such as SQL Injections, Malformed Inputs and Boundary Violations.

Make sure that error conditions or invalid input never expose detailed system information, which could be used to gain control by malicious consumers. Just as for performance testing, the re-use of functional tests for security testing (ie functional security testing) has its benefits, allowing you to scan for security flaws during the execution of functional tests (for example, scanning for SQL Injection vulnerabilities after a client has authenticated with your API).

All these tests (functional, performance and security) would have to be created as early as possible – and preferably run continuously against your APIs as they evolve and mature, either as part of your build of via a separate test execution framework.

Now go ahead to the second article in this series, which focuses on how 3rd party APIs complicate your quality efforts, and how monitoring can help you keep a watchful eye on your APIs after deployment.

See also:

[dfads params=’groups=932&limit=1&orderby=random’]

[dfads params=’groups=937&limit=1&orderby=random’]