How to load tests and what to look for in API testing
APIs are sort of like the glue that holds many of the web's most popular platforms together. For example, Facebook's APIs enable the vast number of services, add-ons and other programs that connect to the social network. This is because an API is an application programming interface, and it contains within it the various protocols, frameworks, etc. needed for accessing a specific piece of software.
Another way to think of APIs are as mechanisms for software-to-software communication. In this capacity, they play a similar role to the graphical user interface (GUI) in interactions between humans and software: They are basically mediators. However, APIs themselves do not have GUIs; there are no buttons to press or bars to scroll through. So how can they actually be tested before being put into production?
The basics of API operations and testing
It is common to talk about "API calls" when discussing APIs. The "call" metaphor is helpful in describing how an API operates, i.e., through messages between it and other pieces of software. The Simple Object Access Protocol (SOAP) API for Salesforce.com is a good example here. Calls to it can accomplish several things:
- Querying, adding, updating and deleting data.
- Acquiring metadata about that data.
- Running utilities that help with administrative tasks.
The actual operation of the SOAP API involves using the API to submit service requests to a web service at Force.com. These calls are synchronous, meaning that the client application waits for a response.
Salesforce.com is integrated with numerous programs through its various APIs, including SOAP. When it comes to testing these APIs, or any others, testers are mostly looking to ensure that API's calls work properly, whether the API is a private API that is integrated into an application or a public API that someone might use to locate a radio station, get GPS directions, etc.
"API testing is in many respects like testing software at the user-interface level, only instead of testing by means of standard user inputs and outputs, you use software to send calls to the API, get output and log the system's response," explained Michael Churchman for the Udemy Blog. "Depending on the testing environment, you may use a suite of prepared test applications, but very often, you will wind up writing code specifically to test the API."
One important thing to note with API testing is that is that it is usually white box testing, instead of black box testing. The distinction can be summed up as:
- White box testing: In this form of testing, the tester is concerned with the internal workings of application development and delivery, not just its surface functionality.
- Black box testing: The opposite of white box testing, black box testing is focused solely on a program's functionality and not on details such as what paths are available to its data.
Since APIs are basically like connective tissue between applications, the more comprehensive white box approach makes sense as a way to ensure that the program it is "calling" works properly. So what would a sample API test contain?
It might consist of a call to the API, along with a way to output and log the results of that call. Since the API belongs to the logic tier of an application - in between the data tier, in which information is stored and retrieved, and the presentation tier, where the GUI is contained - the test should reveal whether the API can successfully handle requests under common conditions.
Everyday "normal" conditions may be first on the list for your API testing regimen. If it works well enough in this context, you will likely move on to load testing to see how much demand the API can handle.
Load testing for APIs
Many APIs handle massive numbers of requests even on a minute-to-minute basis, which explains why major platforms such as Twitter and Salesforce.com enforce rate limits to reduce strain on their services. Even if your API never reaches that scale, you will want to verify its ability to process large and sometimes unusual requests.
To do so, you might start by checking its capabilities in handling:
- Large amounts of incoming/outgoing data
- Long strings and numbers
- Non-ASCII characters and double-byte fonts
- Real-time data streams (if applicable)
- Badly formatted or corrupted data
Ultimately, you will want to make sure the API is easy to access and use, works as expected and facilitates developer productivity. Getting the API right makes the overall security and compliance testing of an application much simpler, since you are verifying that data is only passing through a thoroughly verified interface (i.e., the API). Using a test management solution can support your API testing processes from start to finish.