Newman-One of the ways for API Integration testing

How many hours do you spend manually test the integration of all the request work flow of your website to make sure all APIs works perfectly? Ummm….a lot? at least I spent good amount of time doing this! Isn’t it weird that after writing fancy APIs which handles everything that you throw at, needs to be tested again in case there is a small change in API’s behaviour or functionality while manually testing it?

Well, what if I told you that there is a way out using Postman!!! Postman lets you create collections of integration tests to ensure that your API is working as expected!Tests are run in a specific order with each test being executed after the last is finished.Each test comprises of HTTP request and assertions are written in Javascript to verify the integrity of your code. Since, it is written in Javascript, we have the liberty to manipulate the response received in different ways of which, creating local variables, global variables, running the test in loop are few examples.

We can configure the collection to run against any environment since postman allows you to store specific information about different environments(the base urls, query parameters, request headers etc) and automatically insert the correct environment configuration into your test.

We also have the ability to save the data from the test that has been run and use it in the next tests. For example, you may have an API that requires data received from another API. You can store the response (or part of the response, since it is JavaScript) and use that as part of a request header, post body, or URL for the subsequent API calls.

It looks all good so far isn’t it! What if I told you that we can integrate this in Jenkins too! Wouldn’t it be an icing on the cake? Postman has a command line interface called Newman. Newman makes it easy to run a collection of tests right from the command line. This easily enables running Postman tests on systems that don’t have a GUI, but it also gives us the ability to run a collection of tests written in Postman right from within most build tools. Jenkins, for example, allows you to execute commands within the build job itself, with the job either passing or failing depending on the test results.

Newman can be used for both running or testing the collections. Newman’s ability to integrate it with the CI pipeline makes it stand out. Behind the scenes, Newman is a NodeJS module and one requires to have NodeJS installed on the machine before installing it. Go to comman line after installing NodeJS and trigger the below command to install newman globally.

npm install -g newman

One can install Newman globally using homebrew as well!

brew install newman

Once you have Newman installed and assuming the Postman collection to be ready, trigger the below command to run the

newman run [options] <path_of_the_downloaded_postman_collection_file>

We do have a provision to customise the run. You can retrieve a list of options by running it with the -h flag

Below are the options:

Examples:

Running the collection for n iterations:

Let’s say, you have a data.csv file(example below) with the required data to run you collection,

data.csv

mycollection.json

Command to run with a data file:

newman run mycollection.json -d data.csv

Newman with CI:

Newman, by default, exits with a status code of 0 if everything runs well, such as without any exceptions. Continuous integration tools like Jenkins respond to these exit codes and correspondingly pass or fail a build. You can also use -x or --suppress-exit-code to override the default exit code for the current run. You can also utilise the --bail flag to make Newman stop the run if it encounters a test case error with a status code of 1, which can then be picked up by your CI tool or build system.

Jenkins Setup

Let’s say because of test failure, the build failed. Go to Console output to find out the reason!

Source: Internet

Go back to fix either the code in case of genuine failure or modify the test case! and re run the build. In case of success, the console output looks like below:

Source: Internet

We also have a provision to integrate this with Travis CI and Docker.

Client certificates are an alternative to traditional authentication mechanisms. These allow their users to make authenticated requests to a server, using a public certificate, and an optional private key that verifies certificate ownership. In some cases, the private key may also be protected by a secret passphrase, providing an additional layer of authentication security. Newman provides us a way out by supporting SSL client certificates via CLI options:

newman run mycollection.json  --ssl-client-cert cert.pem --ssl-client-passphrase pass_phrase_cert.pem --insecure

The — insecure is used here to disable the strict SSL. Incase you do have CA certs, then you can provide them using the `— ssl-extra-ca-certs` and the path to the file, that holds one or more trusted CA certificates in PEM format

In short, Newman is an answer for all of our problem related to API Integration testing. So what’s your reason now to still go ahead with manual integration testing???

Thanks for reading this article! Don’t forget to clap 👏 or leave a comment 💬!