Efficient API Testing using Postman: Collections

Postman is an API platform for building and using APIs.

It offers various features that are useful for both developers and testers. One of the core features is Collections to store all your API requests.

A Collection represents a group of requests that are grouped by some criteria (some of them are discussed below).

The reason I am writing this specific post is because I have seen a lot of developers just putting in their requests randomly in the Postman, without any structure. So, when you need any specific request in the future, it takes ages to just get a working request from your existing Collections.
Also, these collections cannot be used by anyone other than the one who created them as no one will be able to understand what the requests mean or represent.

Here I am going to discuss about some basics of collections and how you can manage your postman collections, so that it is structured. To help you save time and create a sharable collection.

Criteria to arrange your collections

1. Domain Driven Design - As the name suggests, since most of the API will themselves be using the DDD, this can be a good starting point.
2. Along the lines of business - A company’s products and services have evolved over time and can point to patterns and standards that can help define your APIs and organization structure.
3. Team Centered Approach - Each team has its own collection.
4. Resource-Centered View - A lot of effort is already put into the API paths and schemas, the same can be used to groups requests into collections.
5. Focusing On Collaboration - If there are groups of requests that you would like to share with other team members, or open as public API, or some other restrictions, you can create collections for each of those groups.
6. Identifying your own approach - If you have some other approach that better suits your requirements like versioning, stages, governance, chose that.

An overview of Collections organised correctly, will help new team members get an overview of the complete application as well.

---

Let's see how you can manage your collections, once you have identified a criteria to organise. Here are some of the ways I have used myself.

Workspace

I have multiple workspaces based on the team/project I am working on:

• A workspace for each Completed Project
• Workspaces which I share with other people
• My personal workspace for POC or things not relevant to any project, but my personal learnings.
• A current in progress workspace for the project I am currently working on
• An archive workspace to move all old API to it, when I feel it is not required right now but might be required later.

Collections

Some of the approaches that I have used for collections are:

• Each project has its own collection
• A sharable read only public collection for different teams to get data using our API
• Collections based on Release targets

Folders

Folders can be used to groups requests inside a collection. Some of the folder structures that I have used are based on:

• Stories
• Resource paths
• API
• features
• Application pages
• Requests that are interdependent and might require to use data from each other

Requests

Almost all request variations are kept inside its own folder. The folder would have requests as follows:

• GET Requests
• POST Requests
• PUT Requests
• DELETE requests
• any other request type
• Different variations of these requests based on different paths

Examples

There is also a feature of examples which can be used to store the executed specific scenario. This includes: complete request with the request body & complete response details.
Each request will have at least one of the following:

• working success scenario
• Failure(error) scenario
• only mandatory fields request scenario
• all fields request scenario
• Specific business scenarios
• Any Complex Bug related scenarios
• Response from different environments(Local, Dev, Staging, etc..)
• Anything else that you think will save time or you would require reference to in future.

---

Benefits of managing your collections in a structured way

1. Easier to find specific requests
2. One click to run complete set of requests in a folder/Collection
3. Common authorization for all the requests in a folder/Collection
4. Common pre-request scripts for a folder/Collection
5. Common tests can be run on the run response for a folder/Collection
6. Common variables can be managed and used through a Collection
7. Can create a fork of a collections so that everyone can use the base collection as reference and making their own changes on it, also creating a Pull request, pulling changes added by other, maintain history for all changes.
8. View Changelog for a collection

Please do share your suggestions, that will help others improve productivity with Postman API testing.