API Testing: Advice, Pointers, Insights

API is code engineer shorthand for ‘Application Programming Interface’ and the name describes its function nicely. An API is an interface to an application that is used by programmers rather than directly by users. API usage is through precisely crafted middleware code that accesses various software functions via distinct protocols.

This is different from calling or linking code modules. The main thrust of the API is to provide a clearly re-useable software service that can be implemented via use of a simple protocol set and is completely isolated from the system using it. In programmer-speak: APIs maintain the object abstraction in object-oriented programming.

APIs typically takes two paths, third-party services and software within a system. Third-party services such as credit card verification, interactive linkage to other sites and access to external databases are commonly used via APIs. In social media, APIs allow the sharing of content and data between communities and applications. They offer specific responses to formatted requests for a wide variety of customer users.

Internal software services, such as between modules in middleware or middleware to and from a system database are increasingly being handled through APIs as well. The API access provides a firewall of sorts against bugs being introduced into its service as collateral damage from code changes to other parts of the system. It does this by being the sole access to its service code.

Properly implemented, a web user should never notice when software functions are being handled by an API. But, like all software systems, things can and will go wrong. When a user triggers an API controlled feature of a web page, it can prompt a response from the site middleware that may well send a request through an API for a particular system or off-site service. So, while the UI and the API are isolated and distinct, they still have to be tested to see that they work together properly.

API Testing Approach

APIs offer the perfect opportunity to have a computer test a computer. The interface itself is intended to be used by code rather than directly by a human and that yields a testing approach that begs for automated test scripts. API use commonly takes the form of Hypertext Transfer Protocol (HTTP) requests, with typical responses in Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format. If you are beginning to suffer from acronym overload, ignore the previous sentence and just know that APIs are accessed through code instructions that have to be functionally verified.

Single call APIs operate through a single access to their underlying functions. An example is a command to delete a record in a database. The call is issued and a result code is returned. Testing such an API is a simple matter of sending enough structured calls to exercise all the permutations of response codes.

Testing Multiple Call APIs

Multiple call APIs are more common, especially for third-party services. Here, series of calls set up conditions for performance of the service which may well result in the return of multiple structured information messages and result status codes. Greater complexity offers more opportunities for defects and requires a test approach that prompts the API through all its paces and especially its error recovery features.

Key to testing multiple call APIs is coordinating setup/request calls to create specific expected result/status responses. As an example, the use of a credit card verification API might involve sending request messages with the customer name, card number, expiration date and verification code followed with a request to charge a specific amount under a specific product code.

There are many data combinations available and they have to be arrayed to prompt the API through all its response permutations. Some of these responses will be confirmation codes, error codes, requests for additional information and fraud alerts. The test code has to prompt the API through all of its potential response paths which means a plethora of calls involving complex test data structures.

API Test Documentation

Documentation may well have become a vilified if not dirty word under the Agile development methodology, but it is essential for APIs. The access to the API, its incoming and outgoing data structures and its response paths must be clearly described. The API’s use documentation should be part and parcel of the test project as verifying it is fully as necessary and testing the code of the API itself.

End-to-End API Use Cases

Once the operation of the API calls has been verified, there is still the matter of what happens when the system uses them in normal operations. This is where the user interface comes into play to exercise the API as part of the system that it is expected to support.

Use cases are the foundation for feature verification and, by implication, API call tests. A test engineer who understands the operation of the system front to rear has to design a set of white-box tests that will exercise the API calls to verify that they are used properly and that the API responses are timely enough to support expected performance levels. API failures must be graceful and supported with pertinent, informative notifications. The entire system has to correctly support the issuance of API call assertions and the implementation of result responses.

Verification of API call operations start with test code written (and hopefully automated) to exercise all features of an API singly and in concert. After they are proven to work on a stand-alone basis, their integration with the rest of the code must be assured.

Contact Us