In the first part of the blog series, we saw how Postman can be installed and how we can use the Postman-BDD library for writing BDD-styled tests for Postman.

In continuance with that, let us start writing some basic tests for our API’s using this library and also, we’ll see how we can use a collection of these tests to run several tests at once. We’ll also got about seeing how we can generate a nice-report our of our tests.

 

API- USED

So, as we, move ahead with our tests, let us a take an REST-API endpoint, that I have been using to test my set up. The API that we’re taking about is coded in NodeJS and returns a JSON response , which we’ll be using to test. The API end point in question is a login API, which uses the GET method of the HTTP protocol, using a Basic Authentication.  To know more about the different types of authentication, read this blog, where it has been explained in depth. The API in question is an Admin login API, with an endpoint like

http://xxx.domain/admin/login

which returns a JSON object, with different keys. We’re going to use our Postman-BDD library and assert that the API-response is correct.

As per the specification received from the Swagger-documentation for this API, the response should be as per this format

Once we have an expected output format, we’re gonna start writing our tests.

Let us start with the very first tests to see if the API- response that we got , is in JSON format  and has application/json in the header.

So, our tests look like this

We click on the SEND button in the API endpoint after selecting the GET method. Here is a snapshot if the response that we’ve got

So, as we can see the API response is a JSON object. There are certain values that have been mentioned hidden [and I didn’t have good tools to edit these pictures].

In the second image below, we’re going to check the Headers tab to check the Request headers for the API. This looks something like this

As you can see, the content-type header shows the value application/json ; charset=utf-8 which is what we have expected in our tests. Let’s look at how our tests fared. We expect both our tests to pass.

 

 

which is exactly what happens in the Tests tab, in the response.

 

So above where quite easy tests that we wrote for the response that we received. Now you can use the power of Postman-BDD library to design these BDD-styled test cases for you.

Adding an example, suppose we hit the API with no authentication at all, let’s see these group of tests

 

In the following images, the following things are being checked –

• Response returned is an error.
• Response should not have an HTTP 200 (Success) code returned in response.
• Response should not send an OK status in response [related to above point].
• Response should not return a client Error code ( HTTP 4xx codes ).
• Response should return a server Error code ( HTTP 5xx codes).
• Response status type should be 5xx.

 

As you see, it’s pretty easy to read and comprehend these API-test cases, since they are written in almost plain text English and a person would have very little or no difficulty understanding these – which is the beauty of BDD testing.

 

RUNNING A GROUP OF TESTS

 

Writing individual tests for each requests is fine, but is not satisfactory.  In BDD we want our tests to be comprehensive, and separate, so that the Project Manager or Business Analyst reading the requirement specifications can have a general idea of the various tests that we have.

 

In Postman, we can have a set of tests written for a specific API and then can be run one-after-other, to test if all of the different set of tests that we have are passing or not. This feature is provided by using Collectionin Postman. You can read more about them here.

 

Now, let’s suppose we have a collection of tests in our Postman, that we want to run. How can we achieve them. This can be done in two ways –

• Using the Postman GUI- Collection Runner

 

If you click on the > button once you hover over to your collection, you can see that all the tests in your API-collection show up. Now you can click on the blue RUN button which will run all the API- tests in the collection one by one.

 

• Use newman CLI to run a collection.

You can use newman runner, to run a collection from the command line too. Since I am a sucker for CLI tools, I am gonna go ahead and demonstrate how to use this CLI tool.

 

USING NEWMAN CLI

 

This is what the Postman docs say about newman

Newman is a command line collection runner for Postman. It allows you to run and test a Postman Collection directly from the command line. It is built with extensibility in mind so that you can easily integrate it with your continuous integration servers and build systems.

 

Newman allows us to run a collection/ or even a single API test in Postman, from command line, and also gives us option of generating a nice-formatted HTML report once the execution is complete. All you know about newman is given here on Postman docs and on it’s Github’s link.

 

To start using newman we need to install it using npm package manager.  You need to run

npm install -g newman

where the -g flag means newman is installed globally and can be run from any directory.

Once newman is installed you can run your API collection by running it’s .json file, which you can generate by using the Export option in Postman,

 

Now you can run this collection from command line as

newman -c collection_name

 

However, we don’t just want to run the tests. We also want to generate a nice HTML report out of it. To do this, use -H flag, along with the name of the report that you’d want. So our command becomes

newman -c collection_name -H reports.html

 

In case you have an Environment, specifically dedicated to testing this collection, you can specify that as

newman -c collection_name -H reports.html -e environment_name

 

which generates a formatted output like this in your CLI

and also generates an HTML report, named reports.html in your pwd.

 

In our next blog post, we’ll learn how we can integrate this newman CLI with a CI-system like Jenkins.