What does pm.test.skip do in a Postman script, and what does the block report?
answer
- Records the block, runs nothing
- The signature takes only a name
- skipped true, passed stays true
- Never lands in the failure roll-up
- Check skipped before reading passed
basics
~20 spm.test.skip(name) emits an assertion record for the named block without running any check. The record has skipped set to true, and its passed flag stays true, so a consumer that reads only passed sees a skip as a pass.
solid answer
~40 s`pm.test.skip(name)` records the block and runs nothing. Its declared signature takes only a name, so if you leave a function as a second argument it is simply never received or invoked — no expectation inside it executes. The record it emits still gets a `name` and an `index`, exactly like a normal block, but with `skipped: true`. The catch is the `passed` flag: a skipped record leaves it at `true`. The Postman runtime's failure roll-up collects only records whose `passed` is `false`, so a skipped block never appears among failures. Anything reading these records must check `skipped` **before** `passed`, or a shelved check will read as a green one.
code
javascript · 3 linespm.test.skip('inventory is reserved', function () {
pm.expect(pm.response.json().reserved).to.eql(true);
});go deeper
Recall that pm.test.skip names a block and runs nothing, and that the block still shows up in the results marked as skipped rather than disappearing.
Explain that the record keeps passed at true alongside skipped, and why anything summarising results must branch on skipped first or count shelved checks as green.
Treat skips as tracked debt: narrow them to the single claim that cannot hold, name them so the report explains itself, and account for the fact that nothing will remind you they exist.
Decide the policy on shelved checks across a collection — when a skip is acceptable versus deleting the claim, and how the team notices a suite that has quietly stopped asserting anything.
## What skip actually does `pm.test.skip(name)` is the sandbox's way of shelving a check without deleting it. It creates the same assertion record a normal block creates, flips one field, and emits it. It does **not** run anything. The function's declared signature takes the name only. That is the part people get wrong: the usual way to skip a check is to append `.skip` to an existing `pm.test(...)` call and leave the body in place — and the body then sits there as an argument that is never received and never called. Nothing inside it runs. No expectation in it is evaluated. It is dead weight the reader can still see, which is exactly the point of shelving rather than deleting. ## The record a skip emits | field | normal block | skipped block | |---|---|---| | `name` | as passed | as passed | | `index` | next counter value | next counter value | | `skipped` | `false` | `true` | | `passed` | depends on the body | stays `true` | | `error` | the throw, or `null` | `null` | | body executed | yes | no | The two rows that matter are the last three. A skipped block occupies a position in the numbering exactly like a live one, and it reports `passed: true` — not because anything passed, but because the flag starts at `true` and only a throw or an async error ever clears it. ## The trap That combination is the whole reason this comes up in interviews. `passed: true` plus `skipped: true` is not a contradiction in the record's design; it means "nothing marked this failed". But any consumer that reduces the record to a single boolean by reading `passed` will count a shelved check as a green one. Concretely, the Postman runtime's failure roll-up gathers the names of records whose `passed` is `false`. A skipped record is never in that set. So: - a suite where every block has been skipped raises no failures at all; - a count of "passing checks" that ignores `skipped` silently includes the shelved ones; - the only honest reading is to branch on `skipped` first, then on `passed`. ## Using it without lying to yourself Skipping is legitimate — a check for an endpoint that is temporarily down, or one whose fixture is not ready — but it is a debt, and debts need a name on them: 1. **Name the block so the skip is self-explaining.** The name is the only text that survives into the report. 2. **Skip narrowly.** Shelve the one block whose claim cannot currently hold, not the surrounding blocks that still can. 3. **Do not skip to hide a real failure.** A failing block is information; a skipped one is silence, and silence reads as green to anything that only looks at `passed`. 4. **Revisit them.** Because skips never surface as failures, nothing in the run will ever remind you they exist. ## Skip versus commenting out Commenting a block out removes it entirely: no record, no name, no index, nothing in the report. Skipping keeps the block visible in the results with its name intact and its position in the numbering, which is why it is the better of the two — the check is still on the page, just not evaluated. That visibility is the only advantage skip has, and it evaporates if nobody reads the `skipped` flag.
- Why can a suite of only skipped blocks report no failures at all?Because the failure roll-up keys on `passed` being `false`, and a skipped record leaves `passed` at `true`. Nothing ran, nothing threw, so nothing cleared the flag. The skip is visible only in the `skipped` field, which a consumer reading a single boolean never looks at.
- How does skipping a block differ from commenting it out?A skipped block still emits a record: it keeps its name, takes its place in the block numbering, and shows up in the results marked skipped. A commented-out block emits nothing at all — no name, no index, no trace in the report. Skip keeps the debt visible; commenting hides it.
saying these in an interview costs you the question
- Thinks skip runs the body and discards its results
- Assumes a skipped record has passed set to false
- Expects skipped blocks to appear among the failures
- Skips a whole script to silence one broken claim
- Believes skip and commenting out are equivalent