Automated Functional API Testing

A hands-on workshop walking from manual Postman collections to running automated functional API tests in a CI/CD pipeline with Newman and Docker.

The Presentation


Workshop Recording


What This Workshop Covers

A full workshop presented at the Testaholics Anonymous Q1 Meetup — taking attendees from manual API testing in Postman to running automated functional tests as part of a CI/CD pipeline.

The journey

Most teams that use Postman never get past clicking Send. The goal of this session was to change that: show how the same collection you build manually can be exported, run headlessly with Newman, and plugged straight into Jenkins or any other CI tool.

Agenda recap

Section Duration Topic
Context 4 min Microservices — why API testing is now non-optional
Strategy 3 min Where API tests sit in the pyramid
Fundamentals 3 min CRUD methods, request anatomy, status codes
CI/CD 2 min Continuous testing — how the pipeline works
Workshop Postman → Newman → Docker with HTML reports

Three layers of API testing

Single API tests — one endpoint, one assertion. Think of these as integration tests: does this endpoint exist, does it return the right shape, does it handle bad input?

Functional API tests — chained requests that mimic a real user flow through the API layer. Login → create order → retrieve order → delete order. No browser needed.

Contract testing — assures that the agreement between a consumer (another service, the UI, a third party) and a provider doesn’t silently break across deployments. Trust Your Integrations covers how to set this up with Pact.

Request chaining in Postman

The key insight that unlocks functional API testing is environment variables as a passing mechanism. You capture the token from the login response and set it on the environment — the next request reads it automatically:

// Tests tab on POST /auth/login
pm.test("Login returns token", () => {
  pm.response.to.have.status(200);
  pm.environment.set("auth_token", pm.response.json().token);
});

Chain enough of these together and you have an acceptance test written entirely at the API layer — faster and far less brittle than the equivalent Playwright or Selenium script.

From Postman to the pipeline

newman run collection.json \
  --environment env.json \
  --reporters cli,html \
  --reporter-html-export report.html

That command runs identically in the terminal on your laptop and inside a Jenkins step. Wrap it in a Docker container and you get a portable, reproducible test environment you can spin up anywhere.

Tools

Tool Role
Postman Write and organise API test collections
Newman Headless CLI runner for Postman collections
Docker Containerised, reproducible test runs with HTML reports
CI/CD (your choice) Trigger Newman on every commit

Resources

Event Details

Format: Workshop
Community: Testaholics Anonymous — Past Events