A Beginners Guide to API Testing

I’ve had some chats to some awesome testers recently and the topic of wanting to “be more technical” has come up. This resonated with me as I’ve been through that journey before and one of the first things that helped me was someone showing me how to test an API.

Don’t worry, it’s actually not scary and is pretty easy to get started with!

What is an API?

Simply put, an API is a way for pieces of software to talk to each other. It allows two applications / components to send and request data from each other.

In this simple example we can see two applications with an API between them with data being sent and received through the API to each component. It doesn’t have to be just two components, not are we limited between the UI and databases, an API can be between any component.

APIs are one directional, a component will use a single request to push data to another or to pull data from another. They are not two way conversations that are kept aline to transfer data (which is what a Websocket does).

What can an API do?

To support the pushing and pull of data from one application to another, an API can make a series of actions. A non-exhaustive list of these actions are:

• POST: Sending new data to something (e.g. writing a new record to a database).
• GET: Requesting data from somewhere (e.g. pulling customer details from a database to show on the user interface).
• PUT: Sending updates to existing data (e.g changing a customer’s name in a database).
• DELETE: Removing data that exists somewhere.

An easy way to remember what these things are is the nemonic CRUD which stands for Create, Read, Update and Delete.

Each of these actions has a triggering request and then a response, which may contain response data but will contain a response status. A full list of response status codes can be found here but generally the biggies are 200 / 201 (everything went well), 400 / 401 (an error occurred with your request) and 500 (a server error – this one is bad).

Why should I test an API?

Headless testing helps us test earlier (pushing left)

Sometimes we might not have a UI to test from, so it’s good to be able to test headlessly (without the UI) as it means we can start our testing earlier.

To test the untestable

Sometimes a UI will stop us doing something bad by cleaning up an input or a request, but that doesn’t mean the API will catch it. We can try to force error states (or naughty strings that form a security risk) by testing from the API directly.

To derisk the product

The API is a part of what you’re building, it’s a part of the product, so we want it to be good. Being able to test it means what we can give confidence that it works and that data is flowing between things well.

It also allows you to check that proper errors have been put in place for bad inputs and requests (see the status codes above) and nice error messages exist in the response text.

It’s technical!

Cracking open the hood of your product and looking at what’s under the User Interface is a great way to start being more technical. It helps you to understand how software works and frankly will make you more marketable to companies.

It’s a good way to start talking to developers to show that you’re a technical tester and start to engage them. This will help you be seen as a trusted advisor and support your efforts in selling testing into the project.

To help automation efforts

The easiest way to get into automation (in my opinion) is to start with the API layer:

1. The Postman tool is super easy to learn automation with and needs barely any coding skills.
2. You don’t have to faff around with UI stuff like clicking and waiting for things.
3. It’s less flakey so you can assert things and be more confident that it’ll work (and need less debugging).
4. In a start up the UI might change a lot, breaking your tests, whilst the API will remain more stable.

What are some API Risks?

Like any part of software we build, an API can go wrong. Here are some of the risks that we can test for by looking at an API:

When we put in something wrong it breaks the system

Sometimes an application will crash or error if it receives the wrong data or data in the wrong format. Does sending a bad request cause a 500 response (one that would indicate a bad crash).

Things don’t fail well / Error messages are not meaningful

When we send bad data to an application we expect things to fail well, but to do that we need a good error response from the API. This should have a good error status message and error message response to pass back to the user.

We send the wrong data from one application to the other

Sometimes we transform data, hard code data responses or use the wrong amount of decimal places; this can cause problems with our processes and functionality of the system. We can use APIs to chase data from one service to another to ensure that it’s correct and good.

Sending too many requests cause a problem / Sending too much data causes a problem

Ever heard of a Denial of Service attack? Thats where a website is bombarded with so many requests that it causes it to crash, then nobody can use it. The same can happen with our applications, so we need to check if sending lots (or really big) requests can be handled okay.

We can extract people’s information without authentication

Can we bypass the UI and make requests for people’s data from the API? That could be a big security risk.

How do I test an API?

Using the browser

In most modern browsers we can open the dev tools to see what the API traffic looks like from the UI to the back end.

1. Right click on your web page and click Inspect to open the dev tools panel.
2. In the dev tools panel find the network tab to see a list of all the API calls made.
3. Use the headers sub tab to see the request that was made to the API.
4. Use the response sub tab to see the data that came back from the API.

Using a tool

You can take the calls you see in the browser and add them to a tool like Postman to be able to make changes to that request and see the responses.

In this example request I’ve taken the URL for the API and asked to POST to it (both of these can be seen from the dev tools or given to you by a developer). I’ve then passed a list of fields and data for those fields to send to the API using a scripting syntax called JSON.

Once I’ve sent the request, the bottom of the screen shows me the status of the request made (this one’s a 200 OK so it worked) and the body of the response. I can check the body to make sure the data I sent is saved correctly.

“But what about errors?!?” I hear you cry. When we put in a bad request and send it, we can see the status of 400 (thats a bad request) and the response body gives us an error message. This error message says “bad input” so tells us that what we sent that API isn’t right or expected.

Automating

APIs are great to automate as they have a predefined set of requests and responses. We can specify a request with a payload and be able to confirm a response status and that things are in the response payload. We can even get fancy and test for responses within a certain amount of time (performance testing).

Most automation tools will allow you to test at the API layer, my favourite to get started with is Postman because it’s easy to use and doesn’t need big coding skills. It comes with some tests built in for you to use!

Postman have some awesome tutorials to help you to learn how to write tests with its tool.