Software tester’s job differs depending on a multitude of factors. There are times when the number of scheduled tasks and tests is extremely high. In such a situation it’s worth searching for new solutions which allow increasing work’s productivity and assure its high quality at the same time. Using various types of improvements, e.g. uploading data with API definitely helps. It saves time allowing a one-time use of many input datasets. Doing it manually would significantly extend the time of testing.
1. WebApi, API, and REST API
However, what’s more essential about API’s functions is using it for tests. It allows checking the validation’s correctness or taking a peek at the backend values which aren’t visible from the frontend side. Before starting API tests it’s worth studying its basic terms and understanding what it is, especially considering WebApi.
WebApi is a communications interface using HTTP protocol and XML or JSON format to send data. It allows access to resources and a quick information exchange with output servers without necessity to generate interfaces, because it returns only data in chosen format.
API, Application Programming Interface, is a set of rules enabling sending data among applications. Many net services offer public API for sending and receiving content from a certain service. API available via the internet and using URL addresses starting with http:// is a net API. Downloading and publishing information on the internet requires so-called requests.
REST, Representational State Transfer, is a standard which establishes the rules of designing API. REST service is based on a HTTP protocol and provides a set of some well received practices that work like a road-sign. It’s a very elastic solution which allows handling many kinds of connections and returning a few types of data. It cooperates with JSON, XML, or YAML. Making a connection, REST API should depend on data provided together with connections such as: user’s ID, token, or API keys.
2. TESTING API
According to ISTQB dictionary, testing API is testing code which is responsible for communication between various processes, programmes, and/or systems. It often consists of negative testing to check the resistance to error handling.
It’s possible to use many tools while testing programmable interfaces. Some of them are mainly for performance tests, some for automatic ones, and others for functional testing. You’ll find a few of them below:
- SoapUI — functional testing of REST and SOAP web services
- Postman — web service REST testing
- Tricentis Tosca — functional GUI testing and test for API protocols
- JMeter — performance tests and functional API testing for, e.g. REST and SOAP web services
- Swagger — inbuilt functionalities allow documenting, standardizing, and testing programmable interfaces
- Fidler — a tool for debugging internet communication with a vast tester purpose and a possibility to test API and provide performance tests, too
- Insomnia
- Rest-Assured
- Katalon-Studio
All the tools allow testing and documenting API.
3. HTTP communication
HTTP protocol contains methods which allow WebApi manipulation. HTTP communication is realized by sending a request to the server which generates a response. An example can be seen on illustration no 1.
Listing 1. HTTP communication based on https://iteo.com/blog/
Illustration no 1. HTTP communication [own coverage]
Let’s analyze the request and response from Illustration no 1. The above request contains:
- HTTP method (GET method in this case) — with its help we determine what kind of operation will be made on a certain resource;
- URL address (in this case https://iteo.com/blog/) — it’s a so called endpoint, an address to which a request is sent;
- Protocol version (in this case: HTTP/1.1);
- Request headers — a location for placing additional information using e.g. a key — value pair. Kinds of headers are determined in advance and the list can be found here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept;
- Request body — a location for placing additional information used while editing/creating resources on the server. In this particular case the body is empty.
Just as a request, a response contains headers and body, too, but it’s preceded by a response code.
Listing 2. Server’s response for a sent request.
Server’s response for a sent request contains:
- Response status line: HTTP/1.1 200 OK,
- Further response headers, e.g. Server: nginx/1.16.1,
- Empty line
- Response’s body
4. The most frequent methods of HTTP
- GET — downloading data from server
- POST — placing new data on server
- PUT — update/modification of existing data
- DELETE — removing data from server
5. Creating requests
By the example of Wage platform https://wageapp.io/ and using https://insomnia.rest/ we’ll discuss all of the most frequently used methods.
The GET method helps download a list of available offer categories.
Illustration no 2 shows a printscreen of a program mentioned above.
Illustration no 2. GET request with help of Insomnia tools
First, we have to choose one of the available methods (GET) and enter an adequate URL address which is a path determining where to find certain resources on the server. In a discussed example the endpoint is {{base_url}}/api/offers/categories where {{base_url}} is an environment variable defined earlier in Manage Environments. Variables enable defining values as environment variables once and referring to this value when it’s needed. Later on, we will use this particular variable. There are two basic methods of conveying parameters. One is conveying them as an URL element using the GET method. The second one is conveying them as a content of the body’s request using POST which will be described in the forthcoming part of the article.
After sending the request presented in Illustration no 2, a whole list of available offers is being downloaded. Undermentioned code from Listing 3 shows a fragment of HTTP response for a sent request.
Listing 3. Fragment of HTTP response — GET method
Response content from the server is saved in JSON format and its structure consists of a key — value pair which is separated by a colon (key : value). In our example the main elements are categories. In JSON format, every definition of an object/element which always consists of more than one field is enfolded by braces. Board elements are put in brackets. The first object of our categories is a category with an ID equal 12, name: “Babysitting”, description ““, and an adequate iconUrl. Apart from the response content, using Insomnia we can read other interesting values. As shown in Illustration no 2, code status is “200 OK” which means confirmation. We can analyze other parameters such as: time, size, headers, cookie, and timeline — an axis helpful in the process of debugging.
The POST method allows sending data to the server and adding a new job offer on a tested website. It’s necessary to fill in an adequate URL address: {{base_url}}/api/offers and send a request. This method enables conveying parameters in the body. Discussed case consists, among others, of parameters such as: type of offer, title, description, price, etc. Entered HTTP request is presented in Listing 4, and Listing 5 show the server’s response. Similarly to the previous case, response status is “200 OK” so the request has been passed successfully.
Listing 4. HTTP request — POST method
Listing 5. A fragment of HTTP response — POST method
In response, we got a unique ID with 1997 value. Thanks to this value we will be able to edit the offer in the next step.
PUT method updates data sent to the server. The difference between POST and PUT is that when the PUT method is called 10 times with the same headers and body, the database will always contain only one resource. Whereas using the POST method creates 10 resources with various IDs. It can update an offer added previously from Listing 4 with ID equal 1997. The endpoint {{base_url}}/api/offers/{offerid} should be supplemented by previously chosen offerid. After modification, the address is: {{base_url }}/api/offers/1997. Now we can properly modify the request body. As an example, we changed two values: the offer’s title and price. The request’s content after modification is shown in Listing 6.
Listing 6. HTTP request — PUT method
As a response we got “status 200” and response body as in Listing 7.
Listing 7. HTTP response — PUT method
The offer has been successfully updated. The last method to discuss is the DELETE method. It allows deleting previously added resources from the server. It deletes a logged in user avatar. To make it happen, we should enter an endpoint {{base_url}}l/api/account/avatar and send a request. As a response we got “status 200” and the response body as shown in Listing 7.
Listing 8. HTTP response — DELETE method
As you can see also in this case the offer has been successfully deleted.
Few words about testing itself — what we managed to do
Just like learning any new thing, at first API testing can seem a bit difficult. The fact is that it’s much easier than we may think. Summing up, a typical path for every request can be presented using Gherkin syntax which is a language for creating test cases of characteristic construction and uncomplicated syntax. Typical scenario includes the following elements — keywords: Feature, Scenario, Given, When, Then, And. In the discussed example, first we chose an endpoint — a location with input data (Given). Then, we performed varied operations using the data (When). In the end we checked if all the actions were fulfilled according to the requirements.
The end
Acquiring the skill of testing API can be highly beneficial, and sometimes even indispensable while working on bigger and more demanding projects. Performing such tests helps verifying a service operation in separation from the visual layer of an app. It allows defining the scope of tests. We can say that it doesn’t test only the part visible for a user, but also the whole tech supply base of a website, as well as net and system services. Using API methods, we can expedite some of the subsidiary tasks such as creating test data which allows their quicker rendering. While performing API smoke tests we can easily make sure that everything works as planned and pass feedback to a developers team. We can also perform some additional operations to create test data and scenarios. Nevertheless, the main asset is that during API tests we can peek at the values which are not visible from the frontend side. Thus, all the technical supply base of the website as well as net and system services are tested.
