We left off part two of this series at a point where we were able to chain multiple requests together through test scripts and environment variables. Chaining requests is extremely handy and is needed for most API testing scenarios. With Postman’s collection runner, you do not need to run each of these requests one after the other though. Using the collection runner, you can execute all requests in a collection with one click. If you haven’t read the previous parts in the series, I would suggest that you start with part 1.
Let’s look at how we can use the collection runner.
- Import the Postman collection for part 3 through the Import Collection modal. Switch to the collections sidebar, click on the import icon and enter this URL: https://www.postman.com/collections/a0715a8730540e86b569
- Set up an environment as shown in part 2. Postman keeps environment values separate from a collection to protect sensitive data like username, tokens etc. that might be present in a collection.
Click on the Collection Runner button in the navigation bar.
- The collection runner window adopts the same basic structure as the main Postman window. On the left, you can see a sidebar that stores all your previous test runs. On the right side, you can see the main collection runner form.
- Running collections is a simple task. All you need to do, is select a collection, an environment (optional), and set the number of iterations (default is 1). While we have discussed data variables before, we’ll cover them in more detail in another article.
Select the “Tutorial – Part 3” collection from the collection dropdown and the “echo.getpostman.com” environment from the environment drop down. We’ll set the number of iterations as 1.
- Hit “Run”. The main screen switches to show that the collection run is in progress. As we just have 2 requests and 1 iteration, the run should get over quickly.
- Once the run is over, you can analyze the run results. Postman also stores your previous run results which let’s you see if your test results have improved over time. Ultimately, your goal would be that 100% of your tests pass. A test which was passing earlier but fails now would be easy to track. We aim to improve the test reporting facilities of Postman a lot more. Expect some really useful features here!
This was intended to be a 3-part series initially but we still haven’t reached the automated part of testing APIs yet. We’ll cover this in the 4th part along with an exciting announcement that we are you sure you will love!
The “How to write automated test with Postman” series
Update: See how to write tests using the newer PM API (known as the