Postman as a full testing tool

Many of us use Postman as a simple tool or program that helps us… “test requests”. I think that would be the first abrupt description that comes to mind. Someone gives us a URL, tells us the method, the parameters and any other details and thus we validate if the result is what we expected or not. This type of scenario is very common for example while developing a service APIs. But if it was only meant to do that, Postman would be nothing more than a fancy curl command.

Certainly Postman is a much more complete tool, with dozens of features to create requests, manage and share collections, synchronize accounts, etc. Among these capabilities is the main topic of this post: the use of Postman as a solution to the creation and execution of integration tests in our service application. With this pseudo-descriptive headline, I’ll try to show you the fundamental steps that allow you to try this.

The Postman tests are written in Javascript and allow you to ensure that your API works correctly and each of the services processes the parameters properly returning the expected outputs, perfectly simulating the experience of a consumer client of your application. It is important to mention that the integration (or end-to-end) tests in Postman are a complement to the unit tests of your application, so I encourage you to work with both pieces when developing a service API. So without further ado, let’s put this into practice.

We will use a public api http://api.icndb.com to create our tests. Here you can get the details of the services available. The first thing will be to create a new collection in Postman and add a variable with the main url. At the end of the article you might download the Postman collection to test it for yourself:

Now it’s time to add a new request to the collection that gets the /jokes /random resource. The result will be something like the following image.

Among the upper tabs you can find “Tests” which is the space to create the tests using Javascript and where you can define assertions on the results and thus confirm that your API works correctly. Postman tests can use Chai Assertion Library BDD syntax. Here you will find the official examples

Following our use case, we will create tests that validate the following aspects:

- Status code is 200
- Body.type = 'success'
- Body.value is an object containing
   - id is a number
   - joke is an string

The below image shows 2 test cases, the first of them validates the status code and the second makes an assertion on the properties of the response body.

If we test the request one more time using ‘Send’ we will see that the tests have been executed automatically and the results displayed in the Test Results tab that confirm our API is working correctly on that endpoint. In the same way, if one of the asserts does not match (we will modify expect from id to be a string), we will see the error in the results.

These simple examples are the mainstay of testing in Postman and by following this approach we will be able to have a much more robust coverage of our API. But, what if our api needs parameters that we do not know, for example, receiving an id to obtain the details of a simple object. To achieve this we will “chain” our requests using variables in the tests. Before finishing let’s see this example in which we want to obtain the details of a specific joke by its id after obtaining a list of them.

As you can see, we add a new line that stores the jokeId in a collection variable (you can also persist it as a global variable). Then we create a new request to obtain a joke by its id implementing the corresponding tests.

Here you can download the test collection to run these use cases yourself.

Thanks for reading!

You can follow me on Twitter for this and more posts :)