How to Do API Testing: Why Bother? What Tests to Run? Best Approach & Tools

How to Do API Testing: Why Bother? What Tests to Run? Best Approach & Tools

Isn't testing at the UI level more than enough? Why should you be testing your application's APIs, as well? What is REST API testing anyway? What more would you gain from testing your software application at the API level, too? And, most of all: how to do API testing?

Especially since API has no GUI...

And what “deeper” layer would you be actually testing? What test types and test cases to use/define?

“Tormented” by all these legitimate questions here? You're entitled to be, since just the idea of getting tangled up in integration complexities, in the “spiderweb” of connections between different networks, systems, sure sounds discouraging.

Especially when you don't see the actual goal of building an API testing strategy. No clear benefits.

Then, let's shed some light on all those “whys”, “hows” and “whens” related to API and testing an app at the API level!
 

1. But First: What Is An API? What Exactly Does It Do?

Take an API (application program interface) as a “mutually intelligible language” that various applications use (and “understand”) in order to communicate. To exchange data.

And this so-called “language” is nothing but a set of procedures, ready-to-use classes, sub-routines and functions that enhance this interaction between:

  • multiple apps
  • components of the same software app 
  • an app and the web
  • an app and another API
  • an application and various external software programs

An API bridges multiple systems together, enhancing the entire data flow taking place between them. 

And here's a practical and more than common example of an API use:

A developer would use the Amazon APIs to trigger an Amazon interface in his own application, at key stages in the customer journey.

But which are the reason(s) why you, as a developer, should be particularly interested in APIs? What's the “API developer experience” all about?

Once the end user interacts with your mobile app, its front-end sends API calls to the back-end system(s) and thus simplifies the whole development process:

  1. you, the developer, don't need to come up with a custom version of your app for every browser or device
  2. you'll get to update your app's back-end system without the need to redeploy the whole application all over again with every change that you'll make to the back-end

And there are many other benefits you can reap, from a developer's standpoint, from adding APIs to your app development:

  • APIs come as building blocks that you get to maneuver, to assemble according to the given app's context. This way, you get to put together the due interactions without the need to re-create the interface each time the connected systems need to communicate.
  • … and those given apps connected via the “API contract” can come in as many “flavors” as possible; that won't impact their “interaction” as long as they use their common language (or as long as they follow their “contract's clauses” if you want)

In short: API is what adds value to any given application.
 

2. What Is REST API Testing?

(Way) Before we go into details on how to do API testing, we need to figure out what testing at the API level really means. And what makes it any different from GUI and functional testing.

But first, let me point out what API testing isn't:

It has nothing to do, whatsoever, with the look and feel of your application. And this because it won't focus on the presentation layer (UI), but on the business logic layer of your app (application user interface) instead. 

… this type of testing will focus on the interaction between the software and the API. Meaning that it will check whether the calls for specific outputs that the app makes get the proper responses from the API.

As simple as that!

API testing is nothing but testing the APIs and the involved integration, ensuring that they work properly. And by “working properly” I do mean:

  • that your APIs delivers the correct output to the software's calls
  • that APIs comply with your standards of reliability, security, performance, functionality

“When can I do API testing?"

There are 3 key stages when you can check your APIs and integration:

  1. during your app's development process
  2. you can do API testing automation while deploying your application
  3. once your API goes live (thus checking your APIs functionality, ensuring that they produce precisely the outputs that they're supposed to)


3. Why Go Beyond the UI Level? Why Test Your App at the API Level, too?

Here's another question that I feel that I should answer before (finally) getting into details on “how to do API testing”:

Why is it important for you to test your APIs, as well? To check the way they interact/exchange data with you software application?

Here are some of the strongest arguments:

  1. you get to make sure that your APIs work precisely as they're supposed to
  2. … to check that all those interactions and data exchanges between various systems, databases, apps, and networks work smoothly
  3. unlike testing “just” the UI, and therefore, concentrating your testing efforts on the user experience only (on validating a particular UX), by checking the underlying APIs you go deeper: you future-proof your app against the unknown
  4. you ensure that your app can handle the load of calls
  5. you check the overall reliability of all the underlying APIs
  6. you get to run your tests at a business logic layer, a layer that you can easily automate
  7. you check whether your APIs work seamlessly across all operating systems, devices, browsers

Moreover (and this is another strong argument), you don't need to wait for the whole app stack to get built for testing your APIs!
 

4. How to Do API Testing? The Right Approach

By far the best way to test your application at the API level is to go bottom up

Meaning to adopt Martin Fowler's pyramid structure: 

Setting up multiple API tests (scenario, contract, performance etc.) on top of a solid foundation made of UI and unit tests.

First, you engage in unit testing and then... you go deeper: you perform tests at the message layer, as well.

Now the very first “condition” that any “how to do API testing” tutorial would point out to you is:

For doing API testing you need to have your app interacting with a given API.

For this, for testing your software's API you:

  1. first, need to use a testing tool meant to drive the API
  2. then to write your own code that you'll be using for actually testing your API

And next: you set up your API test environment!

This is when you:

  1. set the required parameters around your API 
  2. configure your database
  3. configure your server, as well

… according to the app's specific requirements.

Word of caution: once your environment's set up, remember to make an API call just to ensure that everything runs smoothly before you go any deeper into your testing process.

There! You can now mix your app's data with your API tests and check whether your API works as it should once it is set against specific input configurations.

Note: make sure you adjust your API tests to the following input data relevant to your app's scenario:

  • What other APIs could your API interact with?
  • What issues do you hope to track (“fail fast and fail early”)?
  • What aspects are you testing?
  • What is it supposed to happen under common circumstances?
  • What data gets labeled as: “correct output”?
  • What could happen in non-ordinary situations?
  • Which output gets the “pass” status and which one the “fail” one
  • What environment should the API be used in?

The answers to all these questions (plus the more specific one that you'll be adding to this list) will help you define the requirements and testing boundaries.

Next, let's see precisely which aspects crucial for your application you can test at an API level.
 

5. What Precisely Should You Test? 8 API Tests You Could Run

OK, so we've discovered so far:

  • how to do API testing
  • how to set up your testing environment
  • the info that you need to collect for defining your requirements and testing boundaries

Now the question that arises is: 

What will you be testing?

Here are some of the most common aspects of your app that you can test at an API level:
 

  1. usability testing: it checks whether your API is functional, user-friendly and whether it integrates perfectly with other platforms, as well
  2. documentation: checks whether the documentation is appropriate, whether it provides enough (and adequate) information needed during the application-API interaction 
  3. reliability testing
  4. load testing: checks whether the app's capable to handle the given influx of API calls
  5. automated testing: you can automate all your API tests, getting them to run, to execute API regularly
  6. security testing: checks the type of authentication required and whether all sensitive data is properly encrypted over HTTP
  7. functionality testing: checks whether the API does precisely what it's expected to do
  8. negative testing: identifies all the wrong inputs that the user might insert

Note: probably the biggest edge of API testing over GUI testing is that all the tests that you run at the API level can be automated, set to run continuously!
 

6. API Testing Tools

And this is where the “How to do API testing?” question turns into “Which are the API testing tools essential for my toolbox?”

Allow me to name just a few:

  • Charles
  • Runscope
  • Curl
  • SoapUI
  • Postman with Newman
  • dotTEST
  • Cfix
  • Postman with Jetpacks
  • Eclipse SDK tool- Automated API testing
  • TestMaker
  • TestingWhiz
  • CTESK
  • SOATest

Needless to say that this list is an ever-growing one. 

Also, as you can see, similar tools can be used both for unit testing and API testing, since both ways of testing target the source code.

The END! Can't hide that I'm more than curious now: what's your opinion on API testing?

Have you been running tests on your APIs so far? Have you been defining test cases for API testing? Or you didn't yet venture farther than the UI layer?