skip to content

In a Postman script, what does pm.test record when its second argument is missing or is not a function?

level: seniorimportance: nice to knowfreq 28%

answer

  1. The second argument is type-checked
  2. A non-function short-circuits to a record
  3. The passed flag starts true
  4. An empty block reports green
  5. Prove a new check by breaking it

basics

~20 s

A pass. pm.test checks whether the second argument is a function; when it is not, the sandbox emits the block's record immediately with passed true and no error, so a check with no body reports green without testing anything.

solid answer

~40 s

`pm.test(name, fn)` guards on `fn` being a function. If it is missing, `undefined`, a string, or anything else, the sandbox emits the record straight away and returns — the record is named, indexed, `passed: true`, `error: null`. Nothing is evaluated and nothing warns you. That makes a typo an invisible one: `pm.test('status is 200')` with the body accidentally deleted, or a comma dropped so the function became a separate statement, reports a green line forever. `pm.test` also returns `pm`, so calls chain, which means a malformed chain can compile and still assert nothing. The defence is reviewing that every block's body actually contains an expectation, not that the run is green.

code

javascript · 3 lines
javascript
pm.test('status is 200');

pm.test('body has an id', 'todo');

go deeper

for a junior

Recall that pm.test needs a function as its second argument, and that leaving it out does not raise an error — the block simply reports as passing.

for a middle

Explain the guard on the second argument and why the record's passed flag starts true, so a block with nothing to run is emitted green rather than failed.

for a senior

Spot the suite whose checks cannot fail: read block bodies rather than verdicts, and prove a new check by making it go red once before trusting it.

for a principal

Own the review practice that keeps green from meaning nothing — how empty or unfailable checks are caught before they accumulate, and when a claim should be deleted rather than emptied.

## The guard, and what it does The first thing `pm.test(name, fn)` does after building the block's record is check whether `fn` is a function. If it is not, the sandbox emits the record as it stands and returns immediately. The record it emits is an ordinary one. It has the `name` you passed, the next `index`, `error: null`, `skipped: false`, and `passed: true` — because `passed` starts at `true` and only a throw or an async error ever clears it. Nothing distinguishes it, in the results, from a block whose body ran three expectations and satisfied all of them. So the answer to "what happens if I call `pm.test` with only a name" is: **it passes**. Not an error, not a skip, not a warning. A green line for a claim that was never evaluated. ## How this happens by accident Nobody writes an empty block on purpose. The realistic paths are all edits: - a body is commented out during debugging and the `pm.test(...)` call left behind; - a refactor moves the expectations elsewhere and the wrapper is not deleted; - a punctuation slip closes the call before the function argument, leaving the function as a separate expression; - the second argument is a value rather than a function — the result of calling a helper instead of the helper itself. Each of these leaves a script that reads like it checks something and a run that reports it as checked. | what you wrote | what runs | what the report shows | |---|---|---| | name plus a function with expectations | the expectations | pass or fail, honestly | | name only | nothing | pass | | name plus a non-function value | nothing | pass | | `pm.test.skip` with a body | nothing | skipped | | name plus a function declaring an uncalled callback | the body, partly | no record at all | The fourth row is at least labelled. The second and third are the dangerous ones, because they are indistinguishable from real passes. ## Chaining makes it easier to hide `pm.test` returns `pm`, which makes calls chainable — you can write one call after another off the same object. That is convenient, and it is also a way for a malformed argument list to look plausible: a chain reads as a fluent sequence of checks whether or not each link received a function. The syntax does not distinguish a block that asserts from a block that does not, and neither does the report. ## Defending against it Because the runtime cannot tell you, the defences are all upstream of the run: 1. **Read the bodies, not the verdict.** A green run is not evidence that a claim was evaluated; only the body of the block is. 2. **Be suspicious of a block that has never failed.** A check that has been green since the day it was written, across changes that should have broken it, is a candidate for an empty body. 3. **Delete rather than empty.** If a claim no longer applies, remove the block. If it applies but cannot hold right now, use the skip form, which at least marks itself in the results. 4. **Prove new checks by breaking them once.** Point a new block at a value you know is wrong and confirm it goes red. A block that will not fail on demand is not a check. ## The wider point Every outcome `pm.test` can produce follows from one small record and one guard: `passed` begins as `true`, and only running code can clear it. A body that throws clears it. A callback handed an error clears it. A body that never runs — because it was skipped, or because it was never a function — leaves it exactly as it started. That single default explains why an empty block is green, why a skipped block is green, and why the only trustworthy signal in a suite is a block you have watched fail.

  • Why does an empty pm.test block report as passed rather than as an error?
    Because the record's `passed` flag is initialised to `true` and only a throw or an async error clears it. With no function to run, nothing can clear it, so the record is emitted in its initial state. The same default is why a skipped block also carries `passed: true`.
  • What does pm.test return, and what does that enable?
    It returns `pm`, so calls chain off the same object — including the skip form. The convenience is minor; the risk is that a chain of blocks reads as a fluent list of checks regardless of whether each link actually received a function to run, so the syntax alone never proves a claim is being evaluated.

saying these in an interview costs you the question

  • Expects a missing function to raise an error
  • Assumes a green run proves each claim was evaluated
  • Empties a block instead of deleting or skipping it
  • Never watches a new check fail before trusting it
  • Thinks the runner warns about blocks with no body