API Testing

What’s an API?

An API (Application programming interface) is a set of calls that an application does to communicate parts of the application. For example, the user’s view (browser or UI) with some software component (in a remote server or within the user’s computer) that makes the necessary operations for an application to function.

If you are curious about how this looks for a web application, you just need to check the ‘network’ tab on the developer’s tool on your browser. You can see there are many calls happening in the background when trying to reach a website.

Network tab on Chrome for google.com URL

If you click in one of the calls of the left hand side, you will get some information as on the right hand side. The request URL is the address that the call was trying to hit.

For these web calls, there are two main methods: GET (to request some information from the server) and POST (to send some information to the server). You can learn more about other methods here.

The next field is also very important. This is the message that we get from the server when the call is executed. In this case it is 307 (a redirection). If you are curious about what other statuses number mean, you can check this web, if you are a cat person, or if you are more of a dog person this one.

There are two widely used protocols for sending information between devices: SOAP(stands for Simple Object Access Protocol) that sends information with XML format and REST(Representational State Transfer) that sends information with several formats such as json, html, xml, and plain text (see this article for further explanation in the formats).

Tools to test API’s?

Please keep in mind that the tools mentioned below are not the only ones in that you can use for API testing. I’m talking specifically about these ones because they are the ones I’ve used in the past.

In the section after this one, I’ll show an example about how to do an API test.

Swagger:

According to their website, Swagger is an open source and professional tool-set that “Simplifies API development for users, teams, and enterprises”

https://swagger.io/tools/swagger-ui/

I have used swagger UI as a way to easily check API URLs and understand the calls to then add them into my test code, but, I have not tried all the Swagger’s tooling set yet. I think this is a easy way to communicate changes on the API across the team and document it.

Alternatively to this, the developers should document their API calls in some other form, generally some list, as Twitter does here. The problem I have had with this option is that sometimes the documentation might be out of date and then you need to figure out in the development’s code what’s the exact API call. With Swagger, the list of calls should come directly from the code (clarification UPDATE: depending on the API implementation and if the changes are back tracked) , which makes it easier to handle and up to date (clarification UPDATE: you shouldn’t assume anything in testing).

Swagger is supported by SmartBear, same as SoapUI, so for API testing with it, please check below.

Soapui and Postman,

SoapUI is ” a Complete API Test Automation Framework for SOAP, REST and more”. There is an open source version and a professional one featuring more functionality. The API testing part looks like this:

https://www.soapui.org/docs/endpoint-explorer.html

I took the image from their website and it is quite self-explanatory. Besides, there is a lot of documentation to get you started in there.

Postman is a “collaboration platform for API development”. In the development sense, it provides automatic documentation, so there is no problem with developers making change on functionality and forgetting to upload it.

For API testing, it’s very easy to get started. You can create REST, SOAP, and GraphQL queries. It supports multiple authentication protocols (I talk about this later) and certificate management. Please refer to their website for further information.

Wireshark and Fiddler:

These two programs are very useful to analyse network packets. They are powerful programs and a must known for security, network and performance testing and checking the packets at micro level. You can actually see the exact data sent over the network. However, if what you are looking for are tools for API testing, I would probably not go for them but the ones above, because they are more high level and specific for that.

That said, I have used them before in order to test API’s that required specific secure certificates and for debugging issues (specially performance ones). If you are interested in knowing more about Fiddler, I recommend this article. For Wireshark, this one.

https://blog.wireshark.org/

How to do this programmatically?

If you want to add this testing into your automation code, you have some help on with the tools mentioned before. However, there are many ways of doing these type of calls with different programming languages. For example, here is how to do a rest call with python:

import requests
# make a get call
response = requests.get("URL")

# do something with the result
response.status_code # this gives you the status code as mentioned above
response.json() # this gives you a json with the response on it

# make a post call
response = request.post("URL", {json data})

It gets a bit more difficult when you need to add parameters, authentication or parsing some types of data, but there is plenty of documentation about it all. Let’s see an specific example using the API provided by numbersapi.com.

import requests

response = requests.get("http://numbersapi.com/42?json")

print(response.status_code)
print(response.json())

The result when you execute the code above is:

200
{'text': '42 is the result given by the web search engines Google, Wolfram Alpha and Bing when the query "the 
answer to life the universe and everything" is entered as a search.', 'number': 42, 'found': True, 'type': 'tr
ivia'}

With Python, you could play with the json data to easily retrieve and validate the text, or the number, that there is some result…

For more information about what exactly test when testing API, I think this post is wonderfully well explained (they use postman as example).

Why should I care? UI VS API testing

UI (User interface) testing is the best way to simulate the actual behaviour of the users. However, we tend to re-test things in the UI that could be covered already by testing the API (and in some companies this could be done by a different group or team).

Let’s say a developer changes a call for an API. Let this call be the list of movies that someone liked. Now imagine this API call is not modified in some part of the application, the result being the user cannot find its liked movies. What’s happening in the UI test?

We will then get the UI Test couldn’t find an object. This could be due to the API call being wrong or a bug in the automation, an update on the way of the object needs to be retrieved, a button not working properly, the object being hidden somehow…

However, if you have an API test for it, you should be able to understand that the call is not retrieving anything. If you need to verify things such as results of a search, it’s probably best to use API to check the entire list (which could be done with a quick comparison) and let the UI verify that a result appears where it should rather than the result itself. Also, you should be verifying that the API call is correct (and update the test call if it is not).

Level up:

API calls are less likeable to change than UI objects and they generally come in different versions when they do, not to disturb previous releases of the application. This means you might want to add functionality to verify which version is being tested.

It is also interesting to use this to speed up our UI testing. The most common example being the Login method. This method is usually a bottle neck for the rest of the tests, and if it fails, you don’t know what else might be failing or passing and you are blocked until the fix. Whilst it’s super important to have a Login test to make sure that your users can log into the application, performing UI login each time it’s needed for another test, slows down your execution.

Google login screen

What’s the solution? You can use API testing to skip the login bit. Be careful when doing this, it wouldn’t be secure to have an API to do this in production environment. An example could be to set up some unique tokens (see an example about doing this with soapUI here) that are of quick expiration to perform this skip and send it alongside the URL, or have an API call that sets some cookies or session to be logged in.

If you have other repetitive dependent tests, you should consider running API calls for them before continuing with the test that depends on it. This would considerably speed up your test execution and your results would give you more trustful information about the problem.

That said, UI testing is the best way of ensuring everything works as per user behaviour and E2E and integration tests should not be substituted by API tests, use it only as a help and if it is not increasing the complexity and failures of your tests.

Yet another level up: stats

Another interesting thing that you can do thanks to API calls is to find out information about your application and about how users are using it. To analyse and visualise calls in a bigger scale you can use tools such as elastic search and kibana, and even use artificial intelligence to get conclusions from such calls, but that’s… well… another story.