Testland
Browse all skills & agents

postman-collections

Repairs Postman and Newman runs in CI - a reporter that never writes the HTML file the pipeline expects, a nightly job that fires requests as fast as it can until a partner API rate-limits it, or a report with one row per request when the collection asserts a dozen things between them. 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 drives data-driven runs from JSON / CSV iteration files. Use when HTTP API tests are authored in Postman and need to run, pace themselves, and report correctly in CI.

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.

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

Strengthens and speeds up JVM API test suites - assertions so loose that an empty `200 OK` passed for three days, a 220-test suite spending fourteen minutes mostly waiting on sequential HTTP calls, or endpoints exercised through a hand-rolled JDK HTTP client with JSON parsed by hand. Authors REST Assured (Java) tests in the given().when().then() BDD-style DSL: status code and JSON / XML path assertions, authentication (Basic, OAuth2, API key), Maven / Gradle dependencies, JUnit 5 execution, and Surefire / JaCoCo reports for CI gating. Use when the project is on the JVM and its API tests miss real assertions, run too slowly, or are written by hand.

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.