This site uses cookies and by using the site you are consenting to this. We utilize cookies to optimize our brand’s web presence and website experience. To learn more about cookies, click here to read our privacy statement.

The ‘What’ and ‘Why’ of API Testing

Application Program Interfaces (API) testing offers many advantages to a more traditional manual or automated UI approach. In this post, we decipher what web APIs do, what API testing covers, and why testers should care.

What’s a web API?

In cutting-edge software development, it could be said that web APIs (Application Program Interfaces) define the business logic of the application being designed. The specific rules for how users interact with available services and data are typically all embedded within the API, which means they are one of the most centralized ways to define the functional rules for the software.

A web API is a server-side interface that contains endpoints that relay information through request-response protocols (typically through a URI, or ‘Uniform Resource Identifier’). When a query is entered at the end of the URI, a return is sent. Mechanisms known as endpoints show where the resources being requested externally via URI can be found within the API. When a request is sent, the endpoint determines where to find the response. Typical responses to an API request might be pass/fail, data/information, a call to a separate API, or no response at all.

What does API testing cover?

So why do testers need to know how to do API testing? The short answer: for complete coverage! UI testing, either manual or automated, is still just testing the presentation layers to make sure the end user experience matches expectations and meets functional requirements.

So, if solely using UI testing without data-driven API testing, it’s nearly impossible to validate all different possibilities of how a user could manipulate the application and the related sub-applications. The best approach is to test both UI and API.

What’s even more intriguing in agile or waterfall teams looking to reduce the time and cost of testing, API testing can often be done ahead of UI availability. This means QA can have a head start on their work, as well as learn the ins and outs of the software they’re testing.

Developers typically focus on testing the basic ‘happy path’ for their API to make sure it works as designed under optimal circumstances. This doesn’t account for unlikely entries or paths through the application. API testers on a QA team will focus on all the different permutations and scenarios to validate within a single API and among multiple APIs involved in a chain of requests (end-to-end).

Why should testers know API testing?

There are several areas of an application that can be examined with API testing, such as authentication (login/logout, credentials), setting up new entities within the application, unit testing, infrastructure, security and more. A tester should have at least a moderate amount of knowledge of these areas of the AUT (Application Under Test), but there are still plenty of good reasons to test APIs without having this top-down knowledge of the entire system.

APIs are critical to the application functioning as required, so mature software has business processes that are dependent on the API. They have come to depend on APIs working 100% as expected, or else some or all the interrelated parts in a system could break. Thorough API test suites are a simpler and more convenient way to run through a series of checks after a build and they’re generally straightforward to create, automate, and maintain.

Furthermore, API automated testing often takes a fraction of the time as UI automated tests. In some instances, single end-to-end API tests can run in under 1 second, which lends itself well to the latest continuous integration protocols that have builds being deployed multiple times per day.

Instead of investing in the time-consuming task of coding UI automation, firing up different test environments or virtual machines to execute automated tests in various web browsers, organizations are now choosing to ‘reverse the pyramid’ of testing. This mean the once lower-priority unit and service level testing which tended to be out of QA’s purview has shifted to become a major priority in testing efforts, while more traditional functional and regression testing is shrinking.

The bottom line is that API testing offers many advantages to a more traditional manual or automated UI approach. With the right tools and expertise it can supplement existing testing efforts and contribute added capabilities to your testing goals.