In an older Postman collection export, how were tests and preRequestScript stored, and how are they converted?
answer
- Old files held code as one value
- New files hold a listener list
- The conversion is a line split
- exec is an array of lines
basics
~20 sAn older export stored each script as one plain string under tests or preRequestScript. The collection transformer's converter-v1-to-v2.js splits that string on newlines into an event entry whose script.exec array holds one line per element.
solid answer
~40 sThe older generation held scripts as **plain strings**: a whole pre-request script in `preRequestScript`, and a whole test script in `tests`, each one value on the request. The current format instead declares an **`event`** list, where each entry names what it listens for and carries a `script` whose **`exec`** member is an array of lines. The bridge is the collection transformer's **`converter-v1-to-v2.js`**, which splits the old string on `\n` and writes one array element per line, mapping `preRequestScript` onto the `prerequest` listener and `tests` onto the `test` listener. This is the mechanism behind the classic complaint that an old export "lost its scripts": nothing was lost, but a reader that only understands `event` finds no `event` on an unconverted file, so the scripts are present and invisible.
code
json · 5 lines{
"id": "a1",
"name": "Create invoice",
"preRequestScript": "var started = Date.now();\nvar attempt = 1;"
}go deeper
Remember the headline pair: older exports held a script as one plain string, current files hold a list of lines under an event entry. Naming both old keys is most of the answer.
Explain the conversion mechanically — a newline split into script.exec, with each old key mapped onto the listener it corresponds to — and stress that no parsing of the code happens.
Diagnose the symptom out loud: a run where nothing asserts usually means an unconverted older file, not a broken suite. Check the declared generation before touching anything else.
Frame the policy: decide where conversion happens once, so no consumer downstream is ever handed a document whose generation it was not written to read.
## One string, or a list of lines The two generations of the collection format store the same script in structurally different ways, and this is the difference most likely to bite someone in practice. The **older generation** attached scripts to a request as **plain strings**. A pre-request script was the whole text of that script in a single value named `preRequestScript`; a test script was the whole text in a single value named `tests`. There was no list, no listener name and no wrapper object — just a key whose value happened to be JavaScript source. The **current generation** declares an **`event`** array instead. Each entry says what it listens for and carries a `script`, and that script's **`exec`** member is an **array of strings**, conventionally one line per element. Where the old shape had two well-known keys, the new shape has a list of listeners, which is what lets the same mechanism apply at more than one place in a collection. ## The mapping, side by side | Aspect | Older generation | Current generation | |---|---|---| | Where scripts live | `preRequestScript`, `tests` keys | entries in an `event` array | | Type of the value | one string | an object with `script` | | The source code itself | the whole script in one value | `script.exec`, an array of lines | | Which hook it is | implied by the key's name | stated by the entry's `listen` value | | Number of hooks representable | exactly the two named keys | as many entries as the list holds | The `listen` values that matter are **`prerequest`** and **`test`**, and the conversion maps the old keys onto them by name: `preRequestScript` becomes a `prerequest` listener, and `tests` becomes a `test` listener. ## What the converter actually does The bridge between the shapes is a real piece of code in the **`postman-collection-transformer`** package: **`converter-v1-to-v2.js`**. Its handling of scripts is refreshingly literal: 1. Take the old key's string value. 2. **Split it on the newline character**, producing one piece per line. 3. Write those pieces as the elements of `script.exec`. 4. Attach the result as an entry in the request's `event` list, with the `listen` value that corresponds to the old key. That is the whole trick. The array is not a parse tree and the split is not an analysis of the code — it is a line split, and the array's elements are joined back together when the script runs. Two practical notes follow from that literalness: - Because the split is on the newline character, **what counts as a line is exactly what the string's newlines say**, so a file authored on a different platform is worth a glance in the diff. - Because nothing parses the code, the conversion **cannot** fix, lint or modernise a script. Whatever the old file said, the new file says, one line per element. ## Why people say the scripts "disappeared" This is the question behind the question, and it is worth naming explicitly. A consumer written against the current format looks for an `event` list. Handed an **unconverted** older-generation file, it finds none — the scripts are sitting right there in `preRequestScript` and `tests`, but nothing is looking at those keys. The scripts are **present and invisible**, and the symptom is a run where every request fires and no assertion ever reports. The diagnosis is therefore a two-step reflex: - **Read `info.schema` first.** If the file declares the older generation, the missing `event` list is fully explained and nothing is corrupt. - **Convert, then look again.** After `converter-v1-to-v2.js` has run, the same script should be visible as `exec` lines, and a diff is the cheapest way to confirm every old string arrived. ## Getting it right in an interview - Say **strings, not arrays** for the old shape, and name both keys. - Say **`event` plus `script.exec`** for the new one, and note that `exec` holds lines. - Name the converter as the thing that bridges them, and say **what it does** — a newline split — rather than implying it understands the code. - Attribute correctly: `preRequestScript`, `tests`, `event` and `exec` are **fields the collection format declares**; the converter is a file in the transformer package. Do not describe either as an application feature.
- Someone imports an old export and reports that all their tests vanished. What is your first check?Read the file's info.schema. If it declares the older generation, the scripts are still in the preRequestScript and tests strings and nothing is corrupt — a reader that only understands the event list simply is not looking at those keys. Convert with the transformer, then confirm the same lines appear under script.exec.
- Does the exec array mean the format understands the script's structure?No. The array is a list of source lines, not a parse tree, and the conversion is a newline split rather than an analysis. The elements are joined back together to run. It follows that conversion can neither fix nor modernise a script: whatever the old string said, the new array says.
The old shape kept a script as one long ribbon of text; the conversion cuts it at the newlines into numbered strips and files them under the hook they belong to.
saying these in an interview costs you the question
- Says the old generation stored scripts as arrays already
- Claims the converter parses or rewrites the script code
- Thinks missing scripts mean the old file is corrupt
- Cannot name which listener each old key maps onto
- Describes exec as a parse tree rather than lines