In Postman's sandbox, what is `pm.response.to` mechanically, and where do its matchers come from?

## `to` is a getter, not a stored object In a Postman script, `pm.response` is the reply wrapped as the SDK's `Response`. That class has no assertion surface of its own — the sandbox adds one. When it builds the `pm` API, it defines a `to` property on the response with a getter whose body is a single expression: return chai's `expect` applied to that response, then take its `to`. In other words: ```javascript // what the sandbox effectively installs on pm.response Object.defineProperty(pm.response, 'to', { get () { return chai.expect(this).to; } }); ``` Everything about how the chain reads follows from that one line. `have`, `be` and `not` are chai's own language chains, so negation, grouping and message formatting are chai's behaviour, not something Postman reimplemented. ## Two spellings, one assertion Because `pm.expect` is chai's `expect`, these are the same assertion: ```javascript pm.response.to.have.status(200); pm.expect(pm.response).to.have.status(200); ``` The first is shorter and reads better inside a suite; the second is what you fall back to when the subject is not the response — a value you pulled out of the payload, say. Knowing they are the same removes a lot of guesswork about which matchers are available where. `pm.request.to` is installed by the same code path, which is why request-side assertions such as `pm.request.to.have.header('host')` work and read identically. ## Why "getter" matters | Property built as | Consequence in a script | |---|---| | a stored object, built once | every chain shares one assertion's state | | a getter, evaluated per read | each read starts a clean assertion | Because `to` is evaluated on every read, two assertions written one after another cannot leak flags into each other, and a negated chain does not leave `not` switched on for the next line. It also means `to` is cheap to *have* and only costs anything when you actually touch it. One practical consequence: `to` is read as a property, never invoked. `pm.response.to()` is not a thing. ## Where the matchers come from chai out of the box knows nothing about HTTP replies. The sandbox registers a plugin — `chai-postman` — into chai during initialisation, and that plugin contributes the reply-shaped vocabulary: - `status`, `statusCode`, `statusReason` and `statusCodeClass` on the status line; - `header(key)` and `header(key, value)` on the headers; - `body()` on the raw text, `jsonBody(...)` on the parsed payload; - `responseTime` on the recorded duration; - object-kind checks such as `postmanResponse` and `postmanRequest`, used to fail fast when the subject is not the shape a matcher expects. Attribution is worth keeping straight in an interview: `pm.*` is the **sandbox's** surface, `Response` and `Request` are the **SDK's** classes, and the matchers arrive from a chai plugin the sandbox installs. Three different owners, one chain. ## The serialisation wrinkle Adding a helper property to an SDK object has a side effect: it would show up whenever that object is serialised, and a serialised response crosses the boundary out of the sandbox. So the sandbox also patches `toJSON` on both `Response` and `Request` to delete `to` before the underlying serialisation runs and restore it afterwards. The visible result is that a serialised response has no `to` key even though the live object does. If you ever debug by dumping `pm.response`, do not conclude from the absence of `to` that the assertion surface is missing — it was removed on the way out on purpose. ## What this buys you when a test misbehaves 1. **An unknown-matcher error is a plugin question, not a chai question.** If a name is not recognised, you are reaching for something the plugin does not contribute. 2. **A confusing failure message is chai's format.** The subject, the negation and the wording come from chai; the matcher only supplied the comparison. 3. **When the subject is not a response, switch spellings.** Use `pm.expect(value)` on an extracted value rather than trying to bend the response chain around it. 4. **Do not cache `pm.response.to` in a variable** and reuse it across assertions. Read it fresh each time; that is what the getter is for.