Now that we know how to get started with Postman and how to setup authorization on our API calls, it’s time to look at how we can set Postman up for automation testing.
Postman Tutorial Chapters
- Overview – The Ultimate Postman Tutorial for API Testing
- Chapter 1 – Getting started with Postman for API Testing
- Chapter 2 – Understanding API Authorization Options in Postman
- You’re here → Chapter 3 – Using Postman for Automation Testing
- Chapter 4 – Using Test Scripts in Postman
- Chapter 5 – Running Postman in CI using Newman
- Chapter 6 – Creating Mocks with Postman
Organizing tests into collections
If you use Postman to do exploratory testing, you don’t need to worry too much about how your requests are organized and structured. However, once you begin automating your API tests, you will need to be more careful about organization. The main way to organize tests in Postman is with Collections. A collection is essentially a folder where you can store multiple requests to various endpoints. It lets you collect related tests together in an organized fashion and it also makes it much easier to share data between different tests within a collection.
Sharing data between tests
When writing automated tests, it pays to think ahead about what other tests will be built and plan for the future. If you just create various tests without any structure or cohesion between them it will get expensive to update them when things change. For example, let’s look at authorization.
Let’s say you have an API that uses a bearer token to authorize the calls that you make. As we saw in the previous chapter of this tutorial, you can open up the request in Postman, go to the Authorization tab, and enter in your token. With just one test, this is all fine and good, but imagine if you have 25 different endpoints each of which rely on that token and then imagine that the token changes once a month for security reasons. This means that each month you will need to go into Postman, open up each of the 25 requests and update the token in each of them. That sounds like a headache! 🤯
Instead, we can use a collection to save us a lot of that work. If we had all those 25 requests saved into the same collection, we can click on the 3 dots beside the collection and choose the edit option.
We can then go to the authorization tab in there and put in the bearer token and update the collection. Once we have done that we can go to each test in the collection and choose the ‘Inherit auth from parent’ on the Authorization tab.
With this setup, the next time the authorization token expires we only need to go to the collection to update it there. That change is instantly reflected in all 25 of our endpoints. You can imagine how much less work that is!
Variables
Authorization isn’t the only thing that you can easily share between tests with a collection. You can also create variables that can be shared between tests. You can add new variables to a collection by editing the collection and going to the Variables tab.
Much like programming, variables help you reuse values in different places which makes it much easier to manage the data in your automated tests. But when do you use them? Well, let’s take a look at an example to understand this a bit better. For this example, we will use the /posts endpoints of the jsonplaceholder api.
In Chapter #1 of this tutorial, you should have made a collection called jsonplaceholder in that collection, create a GET request and set the request url to https://jsonplaceholder.typicode.com/posts/1. This will give you the data for the post with an ID of 1. We don’t have any checks setup yet (we will get to how to do that soon!), but for now imagine that we are checking the userId for this post to ensure that it is correct. However, we know that posts 1-10 are all supposed to have the same userId and so we want to check each of them. Instead of creating 10 different requests that all do essentially the same thing, we can create a variable in the collection.
Edit the collection and go to the Variables tab. Click on the first entry in the Variable column and create a variable called post_id In the Initial value column, set the value to 1 and then Update the collection.
Now that you have created the variable you need to use it in the request. Go to the request and change the 1 at the end of it to be {{post_id}}.
Now in order to get the data for different posts, all you need to do is change the value of the variable. However, even this method would require some manual intervention, so let’s look at how we can automate it completely!
Collection Runner
The collection runner is a way that you can automate the running of the tests in your collection. Before you open the collection runner, be sure to click on the Save button beside the request so that your changes will be available in the collection runner.
Click on the arrow beside your collection and then choose the Run option which will open the collection runner:
The collection runner will let you execute the tests, but in our case we want to iterate over the same tests a number of times and change our variable each time. In order to do this we will need to provide data input to the test, so let’s quickly create a .csv file that will do that. You can do this in your favorite spreadsheet program, or directly in a text file. Simply create a file that has one column called post_id (note that it is important that the name matches the name of the variable you created) and that has 10 rows with the numbers 1 through 10 on each row. It should look something like this:
Name the file something like post_ids.csv and save it. Now you can go back to the collection runner and use the Select File button to choose that file. When you do that Postman will automatically set the number of iterations to 10 for you since you have 10 entries in your file. Running the test for each of these entries is as simple as clicking on the big, Run JsonPlaceHolder button. This will kick off a test for each of the entries in the .csv file and will fill in the values from that file into the post_id variable that you created.
Summary
You can see in the run results it is telling you that this request does not have any tests. This is because at this point we aren’t checking anything in these requests. In the next chapter, we will take a look at scripting in Postman and how we can use it to check the results of our requests.