Skip to main content
Postman Testing
CHAPTER 14 Beginner

Automating API Testing

Updated: May 13, 2026
25 min read

# CHAPTER 14

Automating API Testing

1. Introduction

In Chapter 13, we learned how to write JavaScript assertions to automatically verify a single API request. However, real power comes from scale. If you have an entire Collection containing the full CRUD lifecycle of an application, testing them one by one is inefficient. In this chapter, we will learn how to use the Collection Runner to execute multiple requests in sequence, pass data between requests, and introduce Newman for command-line automation.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Understand the concept of test suites and automated test flows.
  • Use the Postman Collection Runner to execute an entire folder of requests.
  • Use JavaScript to extract a variable from one response and use it in the next request (Chaining).
  • Understand the basics of Newman for CI/CD integration.

3. Beginner-Friendly Explanation

Imagine a factory assembly line. Instead of a worker building an entire car manually step-by-step, the car moves down a conveyor belt. Machine 1 puts on the doors, Machine 2 paints it, and Machine 3 tests the engine. If any machine fails, the belt stops and an alarm sounds.

The Collection Runner is the conveyor belt for your API requests. You place your requests in order: Create User -> Get User -> Update User -> Delete User. You press one button called "Run". Postman fires them off automatically in sequence, running the tests for each one, and hands you a beautiful final report showing exactly which steps passed and which failed.

4. Real-World Examples

  • The Login Flow: Request 1 sends an email and password. The test script grabs the token from the response and saves it as an environment variable. Request 2 uses that variable to fetch the user's profile. You cannot run Request 2 without running Request 1 first!
  • Data Teardown (Cleanup): A QA engineer runs tests that create 10 dummy users in the database. The final request in the collection is an automated "Delete All Dummy Users" call to keep the staging database clean.

5. Step-by-Step Tutorial (The Collection Runner)

Let's assume you have a Collection folder named User Workflow with three requests inside it: 1. Create, 2. Read, 3. Delete.
  1. 1. Hover your mouse over the User Workflow folder in the left Sidebar.
  1. 2. Click the three dots ... and select Run folder (or click the folder and click the "Run" button in the top right).
  1. 3. The Runner tab opens.
  1. 4. You will see a list of your three requests. You can drag and drop to reorder them if needed.
  1. 5. On the right panel, you can choose "Iterations" (how many times to loop the whole process) and "Delay" (pause between requests).
  1. 6. Click the big blue Run User Workflow button.
  1. 7. Watch as Postman executes them sequentially and generates a visual report of your PASS / FAIL tests!

6. Passing Data Between Requests (Chaining)

This is the most crucial skill in API automation. How do we take an ID from the "Create" response and use it in the "Read" request? We use variables!

In Request 1 (Create User) - Tests Tab:

javascript
1234567891011
// 1. Check if creation succeeded
pm.test("Status code is 201", function () {
    pm.response.to.have.status(201);
});

// 2. Extract the newly created ID from the JSON response
const responseData = pm.response.json();
const newUserId = responseData.id;

// 3. Save it dynamically to an Environment Variable!
pm.environment.set("temp_user_id", newUserId);

In Request 2 (Read User) - URL Bar:

text
1
https://api.example.com/users/{{temp_user_id}}

*Magic! Request 2 automatically knows the ID generated by Request 1.*

7. Introduction to Newman (Command Line)

Postman is a visual GUI app. But what if you want a server to run your tests automatically every time a developer pushes code to GitHub? Servers don't have a screen to click the "Run" button. Enter Newman. Newman is Postman's official command-line companion.

How it works:

  1. 1. You export your Postman Collection as a JSON file.
  1. 2. You run a simple command in your terminal:
newman run my_collection.json
  1. 3. Newman executes all the requests and prints a beautiful text-based test report right in your terminal. This is the foundation of CI/CD (Continuous Integration / Continuous Deployment).

8. Controlling the Flow (Advanced)

By default, the Runner executes requests top-to-bottom. You can override this using code. If a user creation fails, there is no point in trying to update them. In Request 1's test tab, you can write:
javascript
1234567
if (pm.response.code !== 201) {
    // Stop the entire collection runner
    postman.setNextRequest(null); 
} else {
    // Jump to a specific request by name
    postman.setNextRequest("Update User Profile");
}

9. Best Practices

  • Clean State: A good automated test suite should leave the database exactly how it found it. If your suite creates data, the final request in the suite should delete that data.
  • Use Delays: If you are testing a live production API, running 50 requests in 1 second might trigger the API's Rate Limiter, causing your tests to fail with a 429 Too Many Requests error. Add a 500ms delay in the Runner settings.

10. Common Mistakes

  • Order of Execution: The Runner executes based on the order in the Sidebar. If you accidentally drag "Delete User" to the top of the folder, it will run first and fail, causing the rest of the flow to break.
  • Forgetting to save: The Collection Runner uses the *saved* state of your requests. If you edit a test script but forget to press Ctrl+S, the Runner will execute the old version of the script!

11. Mini Exercises

  1. 1. Locate the button to open the Collection Runner in your Postman interface.
  1. 2. What JavaScript command do you use to save a dynamic value into an environment variable during a test script?

12. Coding/Testing Challenges

Challenge 1: Write the Test script for a Login request. The server returns {"success": true, "accesstoken": "abc123xyz"}. Write the code to extract accesstoken and save it to an environment variable named jwt_token.

13. MCQs with Answers

Question 1

What feature allows you to execute an entire folder of API requests sequentially?

Question 2

How do you pass data (like a generated ID) from the response of Request A to the URL of Request B?

Question 3

What is the name of Postman's command-line tool used for running collections in automated CI/CD pipelines?

14. Interview Questions

  • Q: Explain the concept of "Request Chaining" in Postman. How do you implement it?
  • Q: What is Newman, and why would an engineering team choose to use it over the Postman GUI desktop app?
  • Q: Explain the purpose of postman.setNextRequest().

15. FAQs

Q: Can I run a collection periodically on a schedule, like every morning at 6 AM? A: Yes! Postman has a feature called "Monitors" (which we will cover in Chapter 17) that runs your collections on a schedule from Postman's cloud servers.

16. Summary

In this chapter, we learned how to orchestrate complex testing workflows. We used the Collection Runner to automate the execution of multiple requests. Most importantly, we learned the crucial skill of "Chaining"—using JavaScript to extract data from a response (like an ID or a token) and saving it into an environment variable so the next request can use it automatically. Finally, we introduced Newman for command-line execution.

17. Next Chapter Recommendation

What if the backend team hasn't actually built the API yet, but you need to write your frontend code or your test scripts *now*? Proceed to Chapter 15: Working with Mock Servers to learn how to fake an API response.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·