REST API Testing with Postman explained

Software development is facing tremendous growth – applications are increasingly in demand, releases are more frequent, and its quality must be maintained at an acceptable level. Hence, the Quality Assurance team must ensure that the application works the way it is expected to.

Unit Tests and Integration Tests are great to have, but they aren’t enough to test every aspect of the application. What is more, they are the responsibility of a developer, not a QA Tester.

After the tests are conducted by a developer, it’s time for the QA team to test the functionality of an application’s interfaces. There are a lot of different combinations with various technologies and tools.  In today’s article, we will focus on API Testing with an emphasis on the REST API and Postman.

What is an API and why do we need it?

Imagine you have a walkie-talkie, and your friend is on the other end. You press that button, your voice reaches him, and you ask him if it’s raining outside. He hears your voice and checks whether it’s raining. Once he knows the answer, he presses a button and sends the weather information back to you. API can be compared to the walkie-talkie that enables two-way communication. Of course, the idea is far more complex, but I hope you get the point.

API stands for “Application Programming Interface”. Connecting applications through APIs simplifies data exchange between applications, resulting in higher productivity and revenue.

API Testing is a complementary type of both: Unit Testing and End-to-End (E2E) Testing. API Testing provides insight to the eventual problem early in the Software Development Life Cycle (SDLC).

Typically, web applications are made of three layers: User Interface (UI), Business logic, and Database. Unit Testing is done on the business logic level. E2E Testing can be performed only when all three layers exist. API Testing can be done earlier as it is the kind of testing that does not need the UI, and it can be bypassed.

API Testing can run on a service or business layer and can also run using the Black Box method. Black Box means that there is no need to know about an internal code structure, paths, or any other details. This method is based purely on the input and output of the application.

API is used for communication between applications and works in the following way:

Thanks to this method of communication and data transfer, security is ensured. This is achieved with the inclusion of authorisation credentials needed for those Requests.

API uses the most well-known protocols, such as SOAP, REST, and others. SOAP (Simple Object Access Protocol) is based on XML and is function-driven. REST (Representational State Transfer) is based on HTML. It structures its data in XML, YAML, and JSON and is data-driven. It also supports OpenAPI, Swagger and RAML formats. The most common REST HTTP requests are POST, GET, PUT, and DELETE.

When deciding which protocol to use for building your API, you should consider the features or advantages you need the most. Features of SOAP include standardisation and enhanced security, while the characteristics of REST are flexibility and efficiency.

REST API Testing with Postman

API Testing is used for validating APIs as it checks the functionality, reliability, performance, and security. API Testing is done by the URL, which calls the API endpoint. Those calls are named Requests. After sending a Request, we should expect to receive a Response. The response is then compared with the expected results.

A Request comes in a variety of types – GET, POST, PUT, PATCH, DELETE, COPY, HEAD, OPTIONS, LINK, UNLINK, PURGE, LOCK, UNLOCK, PROPFIND, and VIEW. The ones used most are the GET, POST, PUT, DELETE.

The GET Request is used for getting the data from the joint URL (endpoint). No changes are made to the endpoint.

The POST Request is used for sending the data to the endpoint.

The PUT Request creates or updates an existing resource at the endpoint.

DELETE Request is used for deleting data on the endpoint.

The data is sent to the API endpoint through URL and the proper request type. A Response, once received, should contain the code starting with 2**, which means that the Status is OK. Then, the Response is checked with a test.

There are many tools used for API Testing – Katalon Studio, Postman, Apigee, JMeter, Rest-assured, Assertible, Soap UI, Karate DSL, Rest Console, API Fortress, Pyresttest, Hoppscotch, Taurus, Citrus Framework, and Airborne, just to name a few. We won’t explain each and every one of them, however, for the sake of the example, we will stick to Postman.

The overview with Postman starts with setting up an application on your desktop. You can also use it in the browser, whatever works better for you. Before doing anything in Postman, it is good to have Swagger, where you can see all the available endpoints.

With the created Requests, you can use Parameters, Authorization, Headers, Body, Pre-request Script, and Tests. You don’t need all of them in every Request, as some Requests don’t need all of them filled with data.

Our focus will be on the Test area.

For a start, we use Swagger for an orientation point of available endpoints and we create Requests in Postman. After a Request is set up, we click on the “Send” button. We should get the response shortly. A Response should contain “Status: 200 OK” or a similar code status that starts with “2”. In the Body area of a Response, there should be, in most cases, some data that was received from the server. Those data are tested in the Tests area in the Postman.

There are a lot of examples on the web that you can adjust and use in your own Postman tests.

Basic test – checking the Status of a Response is:

pm.test(“Response status”, function () {
 pm.response.to.have.status(200);
 });

There are also tests that check the Body area:

pm.test(“Response should contain”, function () {

pm.response.to.have.jsonBody(“[response_data0:]”);

pm.response.to.have.jsonBody(“[response_data1:]”);

pm.response.to.have.jsonBody(“[response_data2:]”);

});

In those tests, you can use variables to store the acquired data and use them in another test for a dynamic input. Variables or parameters are stored in the following format: {{variable}}.

API tests can be automatised, and they should cover some testing methods from SDLC, including: Discovery Testing, Usability Testing, Security Testing, Automated Testing, and Documentation.

There are a plenty of diverse ways to utilise the tests. We’re describing some of them in the next section.

CI/CD Pipeline

Once prepared, API Tests can be used even further on. One of the possibilities is to use them in your CI/CD Pipeline. What is a CI/CD pipeline?

CI stands for Continuous Integration. CI/CD pipeline is a series of automated steps to deliver the latest software version. Sometimes there is a need to do certain steps manually and it is also possible. The true power of the CI/CD pipeline is its automation. More details about the CI/CD pipeline can be found in the DevOps materials.

If we want to place certain tests in that pipeline, we can also use API Tests that we have already made in the Postman. Those tests should be organised in a logical order. Before including them in the pipeline, they should be tested in the Postman’s Runner and shouldn’t have any errors.

After we ensure that everything works fine, we can export the data from the Postman – we should have Collections.json and Environment.json files.

For running the Postman Collection.json and Environment.json, we should install Newman. Newman gives us the ability to utilise Postman API tests in the CI/CD Pipeline.

For a start, install nodejs. After that, in the command line, run “npm install -g newman”.

Those two files that we have had exported from the Postman earlier should be put together in the same path.

Next, run that with the Newman.

You can do that with the “newman run [collection name] -e [collection environment]” where “-e” stands for the environment parameter.

Besides Newman, we can also use tools for CI/CD like TeamCity, Jenkins, etc.

If you want to use Jenkins instead, there are certain steps you should follow. Firstly, Jenkins should be installed and started. Jenkins Job should be set up as a Freestyle project. Then, add a build step which will execute a shell command that will call the testing script.

For all the details about how to set this up, please search for Newman or Jenkins specialised tutorials.

Common server response codes

Server Response Codes for REST API range from 100 – 500. There are “subcodes” in them as a more specific explanation, but we won’t go that deep in this article. For example, in the 400 series, everybody knows the code “404 – Not Found”.

Below you can find the general overview of the codes:

1** – temporary Responses like “Continue”, “Switching Protocols” and “Processing”

2** – positive Responses from a server like “OK”, “Created”, “Accepted”, etc.

3** – redirection Responses like “Multiple Choices”, “Use Proxy”, “Temporary Redirect”, etc.

4** – this series of Responses is something that in most positive cases you don’t want to see, as some are “Bad Request”, “Not Found”, “Forbidden”, “Unauthorised”, etc.

5** – this series are bound specifically to the server-side errors – the kind you don’t want to see either. Some of them are “Internal Server Error”, “Not Implemented”, “Bad Gateway”, “Service Unavailable”, “Network Authentication Required”, etc.

Best practices and approaches to API Testing

• Start with learning about an application you’re going to test to be able to answer what endpoints are available and what needs to be tested.
• Test Specifications should be precise and detailed.
• Define the scope of the application.
• Define the scope of API Tests.
• Define which Responses are accepted and which are not, in both body and response code.
• Define test cases that are grouped by categories.
• Define users in the early stage of development, if needed.
• Tests should reflect naming from endpoints.
• Parameters should be written in the Test Cases.
• Keep it simple – one functionality, one test.
• Do not connect Tests in between themselves.
• Do not haste with the requests that can do damage to the target system.
• High Test Coverage is achieved both with positive and negative scenarios.

Conclusion

With API Testing, there is a huge area that can be covered and checked. Like anything else, this method is not a “bulletproof” solution either. As a QA, you’ll need to perform all sets and types of different tests to ensure software quality.

Make certain not to overengineer the testing activities. Keep in mind that everything could change in the SDLC process and that you will have to modify a ton of data. You could get stuck in that process, which can negatively impact the project itself.

Keep it simple but effective.