API Testing using Postman & Newman
With the popularization of microservices architecture, APIs became even more popular. As all we know, API stands for Application Programming Interface.
An API is an interface that allows you to build on the data and functionality of another application, while a web service is a network-based resource that fulfills a specific task. Yes, there’s overlap between the two: all web services are APIs, but not all APIs are web services. API is a larger definition, and web service is a more specific definition. If any API is HTTP based, then it is called web service. However, everybody calls it as API testing in the market. That’s why it will be also defined as API testing in this article.
Postman is an application for testing APIs, by sending a request to the web server and getting the response back. According to “businesswire” Postman Surpasses 10 Million Users as API Usage.
As you can see, in early 2015, API developers & Software testers were making less than half a million API calls. Recently, in late 2020, the product reports just over a billion API calls.
Why API testing?
From the quality assurance perspective, we should also clearly understand the importance of the API testing, as we have a chance to find the bugs in an early stage of the software development cycle, since the business logic is mostly developed first. The earlier we find the bug in the software, the less cost and the less effort in the following stages. We can perform API testing within the application prior to GUI testing. Early testing will get feedback sooner and improve the team’s productivity.
Installation
Postman is not only very easy tool to use, but also very easy to download and get started. It is a very straight forward process. You just need to go to the website and download. Based on the preference, it can be used as a native app, or on the web. I would recommend to use native app.
After completing installation those, who want to use dark theme, can easily do it from settings, and change theme.
Start testing with Postman
Basic knowledge of HTTP messages is required. If we want to send a simple HTTP request, we need to provide:
- HTTP method (e.g. GET, POST, PUT, PATCH, DELETE etc.)
- URL (e.g. https://simple-books-api.glitch.me)
- Path parameters(e.g. status)
- Query parameters (optional)
We need to check documentation of a particular API to be sure which method to use, or which query/path parameters we have, whether these parameters are required, or which status code we are expecting…etc.
Swagger Documentation is mostly used across the software industry.
We should first choose our workspace to organize our tests. Default it is given as my workspace, however more workspaces can be added based on the need. This is your personal, private workspace to play around in. Only you can see the collections and APIs you create here — unless you share them with your team. In my case, I named it “KurtWorkspace”.
We can add collections by just clicking + button and then giving a name to our collection. In our specific collection we should also design our folders in a way that everybody can easily understand, especially if we are working in a big team.
We can now execute one just simple request. We are choosing our HTTP Method as GET, then we provide our URL, then just hit ENTER. As it can be seen, we get back one response as a JSON Body, and status code as 200.
We can also get Cookies (if available), and Headers as a response. In addition to status code, we also receive time and size information, which gives us a clue about the performance of the application. After executing our request, we can easily save it inside our collection.
It is clear that it is not an efficient way to test API’s like that. It should be more structured, so that everybody can easily contribute and just by changing one parameter can run it in different environment with different parameters. In order to make it more structured, we should create first new environments.
In each environment, we are defining our environment variables, so that once we change the environment, the value of the variable will also be changed, which gives us a huge flexibility. For instance, in different environment you can set Protocol as HTTP, HTTPS, or localhost with port number. Host represents here Base URL, it can also be named as Base URL, or just URL. As all we know, in different environments, URLs are also changed. Instead of writing each time manually with every change of the environment, it is automatically changed, since it is used as a variable. Path represents here the Resource, which belongs to base URL. “facilities” is here the end point that we are looking for.
We can define query parameters either manually defining on the URL section starting with ?, and following with key and value structure, or we can define below separately, and they will be added automatically to the URL part.
If we have an authentication, we can also define it together with the request. As can be seen below, there are many options available, however the most common used ones are API Key, Bearer Token, Basic Auth or OAuth 2.0. We can define our Authentication also as an environment variable.
If we are making a POST request, we have to define a valid JSON Body.
Approach of API Testing
So far we have provided the basic requirements in order to be ready for the testing. Now we should have a solid testing approach to cover all possible scenarios.
- Verify correct HTTP status code. For instance, creating a resource should return 201 CREATED, and unpermitted requests should return 403 FORBIDDEN, etc.
- Verify response payload. Check valid JSON body and correct field names, types, and values — including in error responses.
- Verify response headers. HTTP server headers have implications on both security and performance.
- Verify basic performance sanity. If an operation was completed successfully but took an unreasonable amount of time, the test should fail.
Our test cases fall into the following general test scenario groups.
- Basic positive tests (Happy path)
- Extended positive testing with optional parameters
- Negative testing with valid input
- Negative testing with invalid input
- Destructive testing
Happy path tests check basic functionality and the acceptance criteria of the API. We later extend positive tests to include optional parameters and extra functionality. The next group of tests is negative testing where we expect the application to gracefully handle problem scenarios with both valid user input
(for example, trying to add an existing username) and invalid user input (trying to add a username which is null). Destructive testing is a deeper form of negative testing where we intentionally attempt to break the API to check its robustness (for example, sending a huge payload body in an attempt to overflow the system).
Based on the requirements & documentation, we write our tests to cover all possible scenarios. To make the Assertion we use Chai Library in Postman.
There is also an option to use Pre-request Script section, which runs before the request is sent. It is very useful, if we want to create something and use it in the same request with the help of set environment variable option. Below example, we create one random user, save it as an environment variable (username), so that we can use it in our POST method as a user.
If we look at our body section, we could see that we use that random user, which was created in pre-request section.
We can share all of our work with our team members by defining team working space, unless we haven’t worked in team working space area. Optionally, we can get a public link to share with others.
We can run the whole suit at once, or we can specify some requests to run by unselecting the others. We can give additional delay, or we can iterate as much as required.
Data Driven Testing
We could prepare one CSV file to execute Data-Driven test. For instance, instead of creating users one by one, we can create one CSV file with many users, and by selecting “Select file” option we can use this file in our test executions. If we click on preview, we could see something similar to below. If you don’t see the values clearly, it is highly possible that you have done a formatting mistake. As it can be seen, it is the same format that we are providing in our POST body.
Newman
If you are using macOS, just run “npm install -g newman”. If you are on Windows, please follow the instructions per document. To be able to get detailed report we need to install HTML report also.
To globally install the htmlextra package:
npm install -g newman-reporter-htmlextraOnce we are ready, we just need to export our collection, together with environment variables.
Then all we need to do is, running following code from the command line.
Now, we can merge our Postman tests with CI/CD tools, and we can also get one detailed HTML report, which shows us total requests, failed tests and skipped tests as well.
Conclusion
Postman is an elegant, flexible platform that is used to build connected software via APIs — quickly, easily, and accurately. It allows us to run all our collection suit at once, which means just only one click we can run hundreds of tests at the same time in a very short time. It allows us also to run our tests through the command line, which gives us a flexibility to merge our tests in our CI/CD tool. With the new release of Postman, a version control capability is also added, which provides Forking, Pull Request & Merging of Collections. If you are in the software industry, it is inevitable to work with Postman :)
Happy testing!
