What is API Testing?

To preface this, I’ve never really read a great deal about API testing.  My opinion here is based on a little bit of reading, and a lot of doing.

If you Google the definition of an API, you get the following:

a set of functions and procedures that allow the creation of applications which access the features or data of an operating system, application, or other service.

That is a little broad.  It encompasses so many different things that it would be tricky to address them in a post that doesn’t make everyone fall asleep.

So let’s narrow the scope of our definition here to what I think the MoT “30 Days of API Testing” event is focusing on: Web API Testing.

What is a Web API?

A web API is essentially a service provided by a company that wishes to allow external third parties access to certain functions or data.  This access can be provided via a Web API.

Let me use a couple of real world examples here.  Where I work, we provide a client-facing API that allows them to make some basic calls over the Internet.  Those calls include

• Making a new user (alters the state on our system)
• Requesting score data for a user (reads existing data on our system)

So a client typically makes a new user over the API.  That user then takes various actions that influence their score (outside of the API, via an app).  The client can then request to see the scores for the same user.

Let’s go into a little more detail about what’s happening on each of those examples.  Web APIs are all about requests, responses, and changes. I won’t go into too much detail here, as there are much better resources available online for these things.  As a quick overview:

Requests

Like in life, requests to an API are an “I would like you to do this for me” request.  In plain English this could be as simple as “Hey API, how long have you been awake?”.

Responses

These are what an API sends back to you after a request.  There’s a wide range of codes that can be returned, and the content will vary based on which code it is.  Continuing our example above, the response here would be 200 with a body of “I’ve been awake for 7 days”.

Changes

Sometimes the requests we make change the “state” on the API’s server/database.  Requests that create something, delete something, or update something are examples of this.   Requests that change the system often influence the response from other requests, so need to be tested in conjunction with those other calls.

What is Web API Testing?

With the above information in mind, let’s think about what testing for something like that would be like.

Testing an API includes doing the following things:

• Making calls directly to it, in the same way that the client will be making those calls.
• Checking that the response to a call is what is defined in the spec, including
  • The status code
  • The response body (if any)
  • Any data types are correct (e.g. float, integer, date-time)
• Checking error codes are returned when appropriate
• Checking that changes occur where appropriate
• Checking that appropriate security is in place
• Checking that paths/urls are as defined
• Checking combinations of calls to see if any state-changing ones break the others

A good spec document should contain information helping you to test all of the above, and make your API testing experience quite pleasant.