API test collection

Billing API
├── 00 Setup
│   ├── POST  /sandbox/reset
│   ├── POST  /sandbox/clock                 → pins the clock to {{clockStart}}
│   ├── POST  /v1/accounts                   → sets {{customerId}}
│   └── POST  /v1/auth/token                 → sets {{accessToken}}
├── 01 Subscriptions
│   ├── POST  /v1/subscriptions
│   ├── POST  /v1/subscriptions              (idempotency replay)
│   └── GET   /sandbox/processor/charges
├── 02 Database
│   ├── GET   /sandbox/db/subscriptions
│   ├── GET   /sandbox/db/invoices
│   └── GET   /sandbox/ledger
├── 03 Plan change
│   ├── POST  /sandbox/clock                 → advances 12 days
│   └── PATCH /v1/subscriptions/:id/plan
├── 04 Invoices
│   └── GET   /v1/invoices?status=open
├── 05 Webhooks
│   ├── GET   /sandbox/events
│   ├── POST  /v1/webhooks/events            (replay)
│   └── GET   /sandbox/ledger
└── 06 Negative
    ├── GET   /v1/subscriptions/:id          (no token)
    ├── POST  /v1/subscriptions              (malformed body)
    └── POST  /v1/webhooks/events            (missing field)

Ordered folders, not a flat list. The run has to be reproducible from a cold environment, which means setup comes first and nothing depends on state left by a previous run.

pm.test("201 with a usable subscription", () => {
  pm.response.to.have.status(201);
  const body = pm.response.json();
  pm.expect(body).to.have.all.keys(
    "id", "status", "plan", "current_period_end", "customer_id"
  );
  pm.expect(body.status).to.eql("active");
  pm.collectionVariables.set("subscriptionId", body.id);
});

pm.test("no second charge on the processor", () => {
  const body = pm.response.json();
  pm.expect(body.count, "charges captured for this subscription").to.eql(1);
  pm.expect(body.total, "total captured, in cents").to.eql(9900);
});

pm.test("proration matches the finance-supplied value", () => {
  const expected = Number(pm.environment.get("expectedProration"));
  const actual = pm.response.json().amount_due / 100;
  pm.expect(actual).to.eql(expected);
});

Asserting the full key set rather than a single field is deliberate. It fails when a field is dropped or renamed, which is the change most likely to break a downstream consumer silently. The other two tests come from different requests in the collection.

scripts/newman.sh rc3      # or: fixed

newman run postman/billing-api.postman_collection.json \
  --environment postman/local.postman_environment.json \
  --reporters cli,junit \
  --reporter-junit-export results/newman-rc3.xml

The two rc3 failures are the point of the exercise. Each one is a seeded defect, and neither is visible from the response of the request that causes it.

JUnit XML output, the format Xray and Zephyr import, so results land in the test management tool instead of a terminal.