Testland
Browse all skills & agents

postman-collections

Authors Postman collections (requests + tests + variables + environments), runs them headless via the Newman CLI, configures reporters (cli / json / junit / html) for CI artifact upload, and uses iteration data files (JSON / CSV) for data-driven runs. Use when the project ships HTTP API tests authored in Postman and the team needs CI execution alongside or instead of the Postman desktop runner.

Install with skills.sh (any agent)

npx skills add testland/qa --skill postman-collections
View source

postman-collections

Overview

Newman is Postman's official CLI for running collections headlessly in CI (newman-readme (opens in new window)). The shape is two-step: author the collection in the Postman app (or import an OpenAPI spec), save it as collection.json, then run newman run collection.json in CI and emit JUnit / JSON for gating.

This skill covers the headless Newman side. GUI authoring inside Postman is out of scope; its reference is learning.postman.com (opens in new window).

When to use

  • The repo contains *.postman_collection.json (or the team exports collections to collections/).
  • API testing is the team's primary integration-testing layer and the team is already in the Postman ecosystem.
  • A CI workflow needs newman run with structured reporter output for PR gating.

If the team uses TypeScript / JavaScript and prefers code-first authoring, evaluate tavern-testing (YAML) or karate-testing (Karate DSL) before adopting Postman/Newman - those keep tests next to source code rather than in a separate JSON artifact.

Install

npm install -g newman

(Per newman-readme (opens in new window).)

For per-project install (preferred for CI determinism):

npm install --save-dev newman

For the HTML reporter (external, separate install):

npm install --save-dev newman-reporter-htmlextra

Running

The canonical invocation (newman-readme (opens in new window)):

newman run <collection-file-source> [options]

<collection-file-source> can be:

  • A local file path: ./collections/orders.postman_collection.json.
  • A Postman Cloud URL: https://api.getpostman.com/collections/....
  • A public-link URL exported from Postman.

Key flags

The flags you reach for first: -e/--environment, -r/--reporters (cli,json,junit,html), --reporter-junit-export <path>, --bail [folder|failure], and --timeout-request <ms>. The full flag table (per newman-readme (opens in new window)) is in references/newman-reference.md.

Worked example

newman run examples/sample-collection.json \
  -e environment.json \
  -d data.csv \
  -r cli,json,junit \
  --timeout-request 5000 \
  --reporter-junit-export results.xml \
  --reporter-json-export results.json \
  --bail folder

(Adapted from newman-readme (opens in new window).)

Reporters

The four built-in / canonical reporters per newman-readme (opens in new window):

ReporterPurpose
cliTerminal output; enabled by default.
jsonFull JSON summary of every request and assertion result.
junitJUnit XML - consumable by GitHub Actions, GitLab, Jenkins.
htmlStatic HTML report; requires newman-reporter-htmlextra.

JUnit is the canonical CI choice - every major CI platform ingests JUnit XML, surfaces test counts on the run summary, and lets the team click through to per-assertion failures.

For richer per-test details (which assertion in which folder failed with which response), pair junit with json and upload both as build artifacts.

Authoring tests inside the collection

Tests live in each request's Tests tab and run in a sandboxed JS environment with pm.* globals:

pm.test('status is 200', () => {
  pm.response.to.have.status(200);
});

pm.test('body is JSON with .order_id', () => {
  const json = pm.response.json();
  pm.expect(json).to.have.property('order_id').that.is.a('number');
});

pm.test('saves order_id for next request', () => {
  pm.collectionVariables.set('order_id', pm.response.json().order_id);
});

Each pm.test('...', () => {}) call becomes one entry in the JUnit XML / JSON output - name them clearly so the CI run summary is readable.

CI integration

A GitHub Actions workflow that runs newman, exports JUnit + JSON, uploads both as artifacts, and surfaces results in the run summary - with if: always() on the upload and reporter steps so the reports survive a failing collection - is in references/newman-reference.md.

Anti-patterns

The common Newman anti-patterns and their fixes - hard-coded URLs and tokens in the collection JSON, running against production, cascading shared-state pm.test blocks, one giant 200-request collection, and missing --bail - are tabulated in references/newman-reference.md.

Limitations

  • No code-first authoring. Postman's authoring story is the GUI; the JSON file is the artifact. Teams that prefer code-first DSLs should evaluate karate-testing or tavern-testing.
  • Sandboxed JS only. Tests can't import npm packages - the pm.* sandbox provides chai / lodash / cheerio pre-loaded; for richer logic, consider Karate or Tavern.
  • No native parallelism inside one Newman run. Parallelize across CI matrix jobs, not within a single Newman process.

References

  • newman-readme (opens in new window) - install, newman run syntax, flags, reporters, example invocation.
  • tavern-testing - YAML alternative.
  • karate-testing - DSL alternative.
  • schemathesis-fuzzing - property-based fuzzing as a complement (not replacement) for example-based collections.

Newman reference

Companion to the postman-collections skill: the full flag table, the CI workflow, and the anti-pattern catalog. Flags and reporters per newman-readme (opens in new window).

Key flags

FlagPurpose
-e, --environment <source>Postman environment file (path or URL).
-d, --iteration-data <source>Data file for iterations: JSON or CSV.
-r, --reporters <name>Comma-separated list: cli,json,junit,html (htmlextra).
--bail [folder|failure]Stop on first error; modifier scopes the bail trigger.
--reporter-junit-export <path>Where to write the JUnit XML (when junit reporter).
--reporter-json-export <path>Where to write the JSON summary.
--timeout-request <ms>Per-request timeout.
--insecureDisable TLS verification (use only against test servers).
--delay-request <ms>Delay between requests; helps when the server has rate limits.

CI integration (GitHub Actions)

# .github/workflows/api-tests.yml
name: api-tests

on:
  pull_request:
  push:
    branches: [main]

jobs:
  newman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - name: Newman run
        env:
          API_BASE_URL: ${{ secrets.STAGING_BASE_URL }}
          API_TOKEN:    ${{ secrets.API_TOKEN }}
        run: |
          npx newman run collections/orders.postman_collection.json \
            -e environments/staging.postman_environment.json \
            -r cli,json,junit \
            --reporter-junit-export results.xml \
            --reporter-json-export results.json \
            --bail failure \
            --timeout-request 10000

      - name: Upload reports
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: newman-reports
          path: |
            results.xml
            results.json
          retention-days: 14

      - name: Surface JUnit results in summary
        if: always()
        uses: dorny/test-reporter@v1
        with:
          name: API tests
          path: results.xml
          reporter: java-junit

if: always() on both the upload and reporter steps is critical - when a collection fails, the reports are exactly when you need them.

Anti-patterns

Anti-patternWhy it failsFix
Hard-coded environment URLs in the collection JSONCollection breaks across staging / prod / local.Move to *.postman_environment.json files; pass via -e.
Storing API tokens in the collection JSONTokens leak into git.Use environment files committed without secrets, or pull tokens from CI env vars referenced as {{API_TOKEN}}.
Running collections in PR CI against productionTests pollute prod data; rate limits trip; observability noise.Always run against a staging or ephemeral env.
Sequential pm.test blocks that share stateOne failure cascades into N false positives.Each request's tests should be independent - use pm.collectionVariables to share derived data, not assertion state.
One giant collection with 200 requestsNewman runs serially; CI time grows linearly.Split into per-domain collections; parallelize at the CI matrix level.
Missing --bail in CINewman runs all requests even after a failure; noisy logs.Use --bail failure for fast feedback; --bail folder to scope the bail to a logical group.

Related skills

api-chaos-runner

Runs the project's existing API tests under injected network chaos - latency, timeouts, dropped connections, bandwidth caps, packet loss - via Toxiproxy (notes on Pumba / Gremlin / LitmusChaos). Builds a per-scenario chaos matrix and reports which assertions break under which conditions, verifying resilience patterns (retry, circuit-breaker, timeout, fallback). Unlike schemathesis-fuzzing and restler-fuzzing, which generate new tests from a schema, this drives your EXISTING example-based suite.

api-testing-overview

Teaches API testing from zero: what functional API testing covers, how it differs from contract testing and load testing, and a decision table that picks one tool from observable project facts (language and build file, whether an OpenAPI or GraphQL schema exists, functional vs spec-conformance fuzzing vs stateful security fuzzing, whether non-engineers read the tests). Names the real options (Postman with newman, REST Assured, Karate, Tavern, Schemathesis, RESTler), gives install and first-run commands with what a passing run looks like, and the traps that bite first: asserting only on HTTP status, order-dependent tests sharing server state, and hardcoded environment URLs and secrets. Use when an HTTP API needs automated tests and no tool has been chosen, or when an inherited suite only checks status codes.

karate-testing

Authors Karate `.feature` files using its Gherkin-flavored DSL for HTTP API tests, leverages the `match` keyword with fuzzy validators (#number / #string / #regex / contains / arrays), runs the suite via JUnit 5 plus Maven Surefire, and produces JUnit XML for CI gating. Use when the project is on the JVM and prefers a feature-file authoring flow over Java-DSL fluent chains; for those fluent chains use restassured-testing, for the same YAML-style flow on a Python/pytest stack use tavern-testing.

restassured-testing

Authors REST Assured (Java) API tests using the given().when().then() BDD-style DSL - status code + JSON/XML path assertions + authentication (Basic, OAuth2, API key). Configures Maven / Gradle dependencies, runs via JUnit 5, and emits Surefire / JaCoCo reports for CI gating. Use when the project is on the JVM and wants type-safe API tests in the app's own language; for a Gherkin feature-file flow on the same JVM use karate-testing, for YAML tests on the pytest stack use tavern-testing.

restler-fuzzing

Runs stateful REST API fuzzing using Microsoft's RESTler - infers producer-consumer dependencies from an OpenAPI spec, drives sequences of requests (POST → GET → DELETE chains), and reports 5xx errors, resource leaks, and hierarchy violations. Wraps the canonical 4-stage workflow (compile → test → fuzz-lean → fuzz). Use when the API is stateful (resources are created, queried, modified, deleted) and Schemathesis's stateless fuzzing is missing the multi-step bugs.

schemathesis-fuzzing

Generates property-based API tests automatically from an OpenAPI 2/3.x or GraphQL schema using Schemathesis, runs them via the `schemathesis run` CLI or as a pytest decorator, configures the canonical checks (status_code_conformance, response_schema_conformance, content_type_conformance, response_headers_conformance, not_a_server_error), and gates CI on schema-conformance failures plus 5xx detection. Use when the project ships an OpenAPI or GraphQL schema and the team wants schema-driven coverage that scales as the API evolves.

tavern-testing

Authors Tavern API tests as YAML files (`test_*.tavern.yaml`) with `test_name` + `stages` + `request` + `response` blocks, runs them through the Tavern pytest plugin (auto-discovered), and gates CI on the resulting JUnit XML. Covers RESTful, MQTT, and gRPC variants. Use when the project runs on pytest and prefers YAML over a Python- or Java-DSL; on the JVM use karate-testing or restassured-testing instead, and for schema-driven property-based fuzzing on the same pytest stack use schemathesis-fuzzing.