How would you prove an old Postman collection's scripts no longer depend on the legacy sandbox globals?
answer
- Passing runs are not admissible evidence
- Warnings count names, not uses
- Make the sandbox refuse the old spelling
- Leave the switch in place afterwards
basics
~20 sAdd the pragma "use sandbox2"; to each script. That opts the script out of Postman's legacy compatibility layer, so any remaining old identifier is undefined and fails, which is the only proof a passing run cannot give you.
solid answer
~50 sA green run is worthless as evidence here, because the **legacy compatibility layer implements** the old names and answers them after warning once. Two signals exist, and only one of them is a check. The **console warning** fires on the first touch of an identifier name, so it tells you a name is used but never how much of the script depends on it — a name read forty times produces one line. The **pragma `"use sandbox2";`** at the top of a script opts that script out of the layer entirely, so a surviving `responseCode` or `tests[...]` is an undefined identifier and the script fails on that line. Migrate script by script: add the pragma first so the run goes red where legacy remains, rewrite each name to its `pm` counterpart, and leave the pragma in place so a regression fails instead of warning.
code
javascript · 3 lines"use sandbox2";
pm.environment.set("token", pm.response.text());go deeper
Be ready to say that old identifiers still work, so running the suite does not tell you whether a script was modernised. Knowing that the evidence is weak is the first step.
Explain both signals and their limits: a first-touch warning per identifier name, and a pragma that removes the compatibility layer from a script so leftovers fail instead of resolving.
Show the migration sequence and what you expect the report to do. Position, numbering and failure messages all change when legacy entries go, and none of those changes is a regression.
Own the enforcement question: decide whether the opt-out pragma is required on every script going forward, since without it a migration silently decays as old scripts get copied into new requests.
## Why a green run proves nothing The premise of this whole topic is that Postman's sandbox **implements** the legacy identifiers rather than rejecting them. A `LEGACY_GLOBS` proxy answers names like `tests[...]`, `responseCode`, `responseBody`, `postman.setEnvironmentVariable` and `postman.setNextRequest`; on first touch of a name it emits a deprecation warning, and then it returns the real value. Behaviour is preserved on purpose. That means the usual evidence an engineer reaches for is inadmissible: - **A passing run** is compatible with a collection that is entirely legacy, entirely current, or any mixture. The results look identical. - **A clean diff review** catches what a reviewer noticed and nothing else, and bare nouns like `tests` and `responseBody` read like ordinary variables. - **Grepping the collection file** is closer to useful, since scripts are stored as source text, but a substring search is easy to fool and does not distinguish a legacy read from a same-named local variable. What you need is a way to make the tool itself refuse the old spelling. ## The two signals, and what each misses | signal | what it tells you | what it misses | |---|---|---| | console deprecation warning | that a given identifier name was touched at least once | how many uses there are; anything in a script that did not run | | `"use sandbox2";` pragma | that this script does not depend on the legacy layer at all | nothing within that script — but it must be added per script | The warning's blind spot deserves emphasis because it silently misleads. Warnings are keyed to the **identifier name**, once. A script reading `responseBody` in forty places emits the same single line as a script reading it once, so counting warnings tells you which names appear and never how big the migration is. Worse, a script that did not execute in that run — a request that was not reached, a folder not included — contributes no warnings at all, so an empty console is not an empty result. ## The pragma is the actual check `"use sandbox2";` placed at the top of a script opts that script out of the legacy compatibility layer. With the layer not installed, a surviving bare `responseCode` is simply an undefined identifier and the script errors on the line that reads it. That converts the situation from *advisory* to *enforced*: instead of a passing run plus a console line, you get a failing script that names the location. Its one limitation is scope: the pragma is script text, so it belongs to that script. Proving a whole collection means every script carries it, which is itself the useful bookkeeping — the set of scripts still lacking the pragma is exactly the set you have not finished. ## What changes in the report when the migration lands Expect the output to change shape, and do not read that as a regression: 1. **Position moves.** Legacy `tests[...]` entries are converted at **script end**, so they all appear after the script body. Rewriting them to current named blocks moves those results back to where the code sits. 2. **Numbering shifts.** Converted legacy entries continue the same `pm.test.index()` counter as current blocks, so legacy and current results interleave in one numbered stream. Remove the legacy half and the indexes of the remainder shift. 3. **Messages improve.** A falsy legacy entry carries a fabricated `expected <value> to be truthy` error, invented from truthiness because nothing was actually compared. After rewriting, the message is whatever the real check reports. If a report consumer downstream was keyed to result position or index, that dependency surfaces here — which is a good argument for not having one. ## A workable order 1. **Pick one script**, not the whole collection, so failures stay attributable. 2. **Add the pragma first.** The run goes red exactly where legacy identifiers remain; that red list is your work item, generated by the tool rather than by reading. 3. **Rewrite name by name** using the current counterparts on `pm`, keeping the change a rename rather than a redesign of what the script checks. 4. **Re-run and confirm green with the pragma still present.** That, and only that, is the proof the script is clean. 5. **Leave the pragma in.** It is the difference between a migration that holds and one that quietly reacquires legacy spellings the next time somebody copies an old script forward. The short interview answer: you cannot prove it by running the suite, because the shim answers. You prove it by removing the shim from the script with `"use sandbox2";` and showing the script still passes.
- Why is counting console deprecation warnings a poor measure of how much legacy code remains?Because warnings are emitted once per identifier name, not per use. Forty reads of `responseBody` produce one line, so the count reflects the variety of legacy names, never the volume. Scripts that did not execute in that run contribute nothing at all, so a quiet console can mean untouched code rather than clean code.
- Why keep the pragma in the script after the migration is finished?Because it is the only thing that keeps the result enforced. Without it the legacy layer is installed again, so an old spelling reintroduced by a copied script warns once and passes. With it, the same mistake fails immediately on the line that made it.
saying these in an interview costs you the question
- Accepts a passing run as proof no legacy globals remain
- Treats warning count as a measure of remaining work
- Expects the pragma to apply to a whole collection at once
- Reads shifted result numbering after migration as a regression
- Removes the pragma once the script goes green