Testing is an essential part of the software development process. Without testing, developers would be unable to ensure a product is functional, or discover and root out bugs from their applications.

As a result, it is an industry-standard for any piece of software to undergo many rounds of rigorous and repeated testing. Both fully-fledged applications and software components that support those applications must be included within the testing process.

Application Programming Interfaces or APIs are no exception. APIs are widely used components in many of today’s most popular applications and platforms. APIs enable separate software components to communicate with each other in a standardized language. This intrinsic feature drastically cuts down the development work needed to make those components talk to each other, which makes application building easier on developers. With APIs now integral to the functionality of our applications, it is only logical they are rigorously tested like any other software type.

In this post, we’ll introduce web API testing, specifically of the REST variety. We’ll also delve into nine best practices developers should adopt for API testing, such as using a comprehensive API testing tool, among others.

Before that, though, the following is a brief refresher on REST and REST APIs.

What is REST, and what are REST APIs?

REST stands for Representational State Transfer, a type of architectural design pattern for APIs. It is a predominant development style for web applications and services. APIs that are designed with REST are called REST APIs, and they allow web applications and services to interact with resources stored in a web server. These interactions typically take place over HTTP and usually consist of the following:

• GET (retrieval of the resource)
• POST (creation of the resource)
• PUT (updating the resource)
• DELETE (deletion of the resource)

For example, these HTTP methods can be seen in action within the Instagram API. When a developer uses the Instagram API in their application, they enable that application to access the resources stored in Instagram’s web servers. The GET function in this instance can be used by the application to pull up a specific image stored in Instagram’s servers. POST allows it to post content to the server, while PUT gives it the ability to update that content as they see fit. DELETE, logically, lets the application delete the content from the server.

Now that REST and REST APIs have been defined, here are the best practices that every developer should adopt when testing their REST APIs.

1. Use a comprehensive API testing tool.

When it comes to testing APIs, using a comprehensive API testing tool is essential. API testing tools allow for hassle-free testing, measurement, and tracking of API performance and functionality. Some particularly powerful testing tools even offer extra features, such as allowing the developer to create multi-step testing scenarios for automated REST API testing, as well as automated API documentation. Many of these tools are available for download completely free of charge, while others require a purchase.

2. Always start with API smoke and sanity testing.

When a new API is put up for testing, the very first test that it ideally should undergo is what is known as a “smoke” test. A smoke test is essentially a quick-and-ready test to validate the API’s code and ensure that its basic and critical functionalities work. As such, a typical API smoke test could be the following:

• Call the API to check if it responds.
• Call the API using a regular amount of test data to see if it responds with a payload in the correct schema.
• The same step as above but with a larger amount of test data.
• Test the API and how it interacts with the other APIs and components it’s supposed to interact with.

By going with a smoke test first rather than starting with a full test, major errors and flaws can quickly be spotted and identified for immediate resolution. This can help decrease overall testing time, especially in between builds where testers and users are often impatient. Thanks to Patrick Poulin, CEO of API Fortress, for the smoke test example.

Meanwhile, sanity testing involves checking to see if the results that the smoke testing comes back with makes sense when put in the context of the API’s main purpose. For example, if the API is supposed to bring back specific foreign currency exchange rates, such as US dollars to Japanese Yen, then the results should display as intended. The results should not depict an exchange rate that is wildly divergent from the current exchange rate. In essence, sanity testing verifies the API is interpreting the results and displaying the required data in the correct manner.

3. Simulate production conditions for the API during testing.

During the testing phase, developers should always try to simulate the exact conditions the API will encounter in an official production or public release capacity. Doing so will ensure that the test results accurately reflect not just the API’s ability to correctly function, but also to perform adequately when subjected to its intended working environment. This can also clue testers in for any performance issues that need resolving.

4. Ensure that all API responses are tracked and saved for posterity.

Many API developers and testers often discard the responses made by their API during its testing procedure. This is a mistake, as such responses should be tracked and recorded for posterity instead. The reason for this is that the replies an API makes during testing are essentially benchmarks of how it functioned in its specific build at the time. As such, when the API has undergone many changes in the future, and one of those changes results in an error, the tester or developer can go back and examine the saved responses from previous builds. This can help them figure out exactly which modification is causing the error.

5. Make sure to perform “negative” testing.

Testing and monitoring for positive responses, i.e. inputting valid data and checking to see if the request is completed, is a staple in API testing. With this in mind, performing tests for negative results should also be performed with equal diligence. By performing negative testing, a developer can see whether or not their API can deal with receiving incorrect or invalid data gracefully, such as with an error message instead of a hard crash or a full stop. This contributes to the completeness and elegance of an application, as well as being accommodating to user error.

6. Mock missing APIs and components.

Testing an API usually involves many other components connected to that API in the testing procedure. This is done to get the most accurate and natural results. However, there may come a time when certain components or even other APIs may be missing or unavailable during the testing procedure. This can result in unforeseen and costly delays, which can be remedied by replacing missing components with mocked-up versions of themselves. These mock components can not only stand in for their absent counterparts but can also be customized to deliver the ideal responses needed to complete the testing procedure.

7. Remove dependencies when possible.

Besides relying on all components to be present, API testing may also depend on external elements to progress, such as 3rd party services, legacy systems, servers, and so on. These are called dependencies. Even internet connectivity can be considered as a dependency, especially if the developer is in an area where internet outages are common. These external dependencies should also be done away with for a faster and more efficient testing procedure.

8. Don’t neglect security tests.

In this day and age, cybercriminals are always trying to attack businesses and organizations through their applications and services. As such, all APIs must be checked for security flaws and exploits. Thankfully, many testing tools offer security tests and scanning as part of their list of extra features. However, these tools may not detect serious or unforeseen security vulnerabilities that could ultimately lead to a data breach, such as zero-day exploits. A security specialist is recommended in this case.

9. Enforce Service-Level Agreements (SLAs) during testing.

API developers and testers should also ensure that SLAs are enforced during testing procedures, especially if the API’s development has progressed to the point that it is fully functional for its purpose. Doing so allows testers to easily check if the API is suffering from performance issues, and identify them as needed. By having such issues discovered and patched out during testing, the API’s public release will have an easier time keeping within SLAs rather than breaching them.

Final Thoughts

REST API testing is an indispensable tool in ensuring a polished final product. API testing may seem like an added step to the development process. However, seeing as APIs do govern a significant part of an app’s functionality, they should be as rigorously tested like every other component within the app itself. REST API developers, testers, and users should keep the above best practices in mind as they perform their testing procedures to gather the best results.