Testing APIs with Postman: 10 common challenges & solutions

Writing tests in Postman is well documented both on the official site and on the accompanied blog. By testing APIs with Postman, you can ensure a well-structured output for API clients. This post focuses on the hows of Postman and will not go into whys.

Why would I read this?

In this post I will give you a quick-start of writing tests in Postman and show you how to overcome 10 challenges I have encountered using Postman for testing. I am sure it will help you to use features of Postman in order to test your APIs better.

Source code

Feel free to download the example collection and the server stub used in this article, and try everything for yourself in a local environment.

How it works

Basic interaction with Postman consists of creating a request and inspecting its response. The ability to execute code before request and after response makes sure there is a basis for writing tests inside Postman.

Arrange, Act, Assert

The famous AAA pattern of testing:

Arrange all necessary preconditions and inputs.

Act on the object or method under test.

Assert that the expected results have occurred.

Arrange

Arrangement is done inside the Pre-request Script tab. You can run code here to prepare the environment: initialise local variables, get/set global or environment variables, access the pm.request object, make http requests, etc.

Act

Action part is the request itself.

Assert

Assertion is done in the Tests tab. Test code is executed after the request is sent, thus allowing you access to the pm.response object. The pm.expect() assertion function was built on top of the popular JavaScript test library ChaiJS BDD.

Grouping requests

In Postman, you can group requests into Collections. Within Collections, you can group requests into Folders.

Pre-request Script tab and Tests tab also exist on both Collections and Folders level. This feature enables arrangement and assertion on a group of requests.

You can find these tabs by clicking on options of the Collection/Folder and choosing Edit. Any code you write here is applied to each request within the selected Collection/Folder.

Running tests

Single request tests are run simply by executing a single request. Collection tests are run on collections of requests from within the Runner.

Test options

There are a couple of options you can set when running tests. First and foremost, you can select a specific Collection/Folder and the environment you want to run your tests in.

You can set the number of iterations and some other options like delay, logging etc. You can also import test code and export test results.

Challenges & Solutions

While using Postman for testing APIs, I have encountered some challenges and, surely, few more people have.

#1 Reusing tests

As mentioned before, tests can be written for a group of requests. This implies reusing tests - any test you write in the Collection/Folder is applied to each request within the Collection/Folder.

#2 Grouping tests (an example)

Let’s say you have an API with product and user resources. Usually, you would have a GET /products request and GET /products/:id request. The same goes for user resource.

Now, if the API has some standardised response (for example the json:api), GET /products (GET /users) would have a response similar to this:

The testing structure of our resource lists could consist of tests:

1. response body has data key
2. data is an array,
3. each data object has only id, type and attributes keys.

These test would be applicable to both (all) resources.

So, let’s create Collection tests according to the criteria mentioned above.

Since we want these tests to be applied only on GET /products and /users requests, we set an environment variable within the Pre-request tab for each of these two requests.

For example pm.environment.set("testsGroupName", "list")

Collection tests we created before will be applied to every request within our collection. And we don’t want that, so the last thing to do is to go back to the collection tests and create an if statement.

You could go on and create tests for other requests and end-up with something like this.

With this setup, if you send a request GET /products and go to the Test Results tab, you will have 6 test results.

Note: This solution is far from perfect, but its purpose is to show you how the pieces connect. I will show you a more elegant solution in Challenge #5.

#3 Skipping certain requests

Runner runs the collection requests sequentially, in any order you arrange them. In a real-world API, you would perhaps want to skip some requests.

You can explicitly set the execution order by calling in the Pre-request tab, thus skipping all of the requests between the current one and the referenced one -postman.setNextRequest(<next request name>).

You should be careful here because you could break your tests or simply skip some of them without even knowing, especially if you are collaborating and sharing your postman collection. You could also end up in an infinite loop, since this is basically a go-to command.

#4 (Re)using custom functions

All of the code you write in Pre-request Script and Tests tabs runs in a sandboxed JavaScript environment. You can use eval() function inside this sandbox. This way you can load custom code into Postman. And by assigning its value to a global/environment variable, you can reuse it across requests.

#5 Simplifying tests grouping

Now that we know how to reuse functions, we can create a group of tests as a function inside Collection and then reuse it across requests within Collection:

By evaluating the environment variable listTests, we add all the tests defined in it to a specific request (or Collection/Folder).

#6 Using external JavaScript libraries

Postman Sandbox API allows you to use commonly used libraries and utilities. For example, you can use the moment.js library:

#7 Validating responses against a schema

You can use the built-in tv4 library (Tiny validator form JSON schema) to validate the response against a schema.

#8 HTTP requesting

Use pm.sendRequest to make http requests. For example, you can load schema from a url.

#9 Debugging

Turn on the Postman Console window on the Postman status bar in order to debug tests execution. Your console logs will end up here.

#10 Integrating tests with CI

Runner has a CLI version called Newman. It is essential for automation and integration with CI.

npm install -g newman
newman run my_collection.json -e dev_environment.json

Q&A

If there are some other challenges you have encountered yourself, feel free to leave a comment, so we can find a solution together.

_____
If you’d like to join our team, send us your application.