After recording a checkout journey with JMeter's recorder, what does the plan still need before it can replay?
answer
- Recording captures one session, not a rule
- Some headers never reach the plan
- One auth scheme is left behind untouched
- Server-generated values arrive as literals
basics
~20 sA recording is a draft. JMeter strips the Cookie header and adds no Cookie Manager, leaves every identifier the browser sent as a literal, and stores each asset as its own sampler. State handling, correlation and pruning are still yours.
solid answer
~40 sThe recorder captures what happened once, not what should happen again. Three gaps matter. **State**: the browser handled cookies, so the proxy passes them along but always removes the `Cookie` header from generated Header Managers and saves no HTTP Cookie Manager — you add one. **Credentials and ids**: a `Basic` or `Digest` `Authorization` header is lifted into an HTTP Authorization Manager on the target controller, but a `Bearer` token is left in the Header Manager exactly as recorded, and every order id, CSRF token and session parameter in a URL or body is a literal. **Shape**: unless you filtered, every asset is its own sampler, and redirect chains appear twice — JMeter disables the duplicate and comments it when `proxy.redirect.disabling` is on. Extracting the dynamic values is `dev-jmeter-data-regex-boundary` and `dev-jmeter-data-structured` work.
go deeper
Understand that a recording is a draft. Know that cookies are not saved into the plan and that a replayed plan needs a Cookie Manager added before it behaves like the browser did.
Explain exactly what the recorder drops, what it lifts into an Authorization Manager, and what it leaves as a literal. Be able to describe why a redirect chain contains a disabled sampler.
Walk a real cleanup: prune, add the managers, hunt the hard-coded bearer token, name the steps, correlate the server-generated values, then replay one thread with assertions before trusting anything.
Insist that a recorded plan is not a deliverable until the correlation is done and reviewed. A plan that replays literals returns green results while testing nothing, which is worse than no test.
The honest summary of JMeter's recorder is that it produces a **starting point**. It is very good at the thing that is tedious by hand — discovering the exact sequence of requests, methods, parameters and headers a journey makes — and structurally incapable of the thing that makes a plan re-runnable. Knowing precisely which is which is the difference between a recording that becomes a test in an afternoon and one that is quietly broken for weeks. ## What the recorder deliberately drops Some of what the browser sent never reaches the plan, by design: - **`Cookie`** is always removed from the generated Header Manager. During recording the browser held the session; a recorded cookie value would be stale on the next run. The recorder does not add an HTTP Cookie Manager either, so a replayed plan is stateless until you add one. What that element then does with cookies belongs to `dev-jmeter-protocols-http-state`. - **`If-Modified-Since`**, **`If-None-Match`** and **`Host`** are removed by default, controlled by the `proxy.headers.remove` property, which takes a comma-separated header list. The first two are conditional-request headers: keeping them would make a replay ask for "only if changed" and record 304s instead of content. - Requests that failed the content-type or URL filters were never recorded at all. ## What it lifts into an element An `Authorization` header is treated specially. The recorder reads it, works out the scheme, and builds an Authorization Manager entry on the target controller — reusing one if you added it there yourself. `Basic` credentials are Base64-decoded into user and password fields; `Digest` and Kerberos entries are written with `${AUTH_LOGIN}` and `${AUTH_PASSWORD}` placeholders for you to fill in. The header is then removed from the Header Manager. **`Bearer` is the exception.** The recorder recognises it, declines to build an Authorization Manager from it, and leaves the header where it is — so a bearer token sits hard-coded in the recorded Header Manager and stops working the moment the application stops accepting it. On any modern token-based application, that is the first thing to correlate. ## What it leaves as a literal Everything the server generated and the browser echoed back is captured as text: the order id in a URL path, the CSRF token in a form body, a cart id in a query string, a view state in a hidden field. Replay them unchanged and the application will reject them — usually with a `200` and an error page, which is why a recorded plan can look green while doing nothing — `dev-jmeter-verify-silent-failure` owns that failure mode. Turning those literals into extracted variables is correlation, and the extractor elements that do it are `dev-jmeter-data-regex-boundary` and `dev-jmeter-data-structured` material. The recorder does offer one substitution of its own, at record time: place **User Defined Variables** in the target controller (or inside the recorder element to override them) and every occurrence of a variable's *value* in a recorded sampler is replaced by `${name}`. Matching is case-sensitive, and with **Regex matching** ticked each value is compiled as a regex wrapped in word boundaries. That is right for constants you already know — host names, a base path, a fixed account — and useless for values the server invented during the session. ## What it leaves in the wrong shape - **Asset noise.** Without filters, one page arrives as dozens of samplers for images, CSS, fonts and analytics beacons. - **Redirect duplicates.** The browser followed each redirect, so both the original and the redirected request were recorded. With `proxy.redirect.disabling` on (the default) JMeter compares each request against the previous response's `Location`, disables the duplicate, and comments the samplers "Detected the start of a redirect chain" and "Detected a redirect from the previous sample". Turn that property off and you get both, live, and the plan will follow the redirect *and* replay it. - **Names.** Unless you drove the Transaction name field while browsing, the samplers are named after paths. ## A working cleanup order 1. Delete the samplers that filters should have caught, and fix the filters before the next recording. 2. Add an HTTP Cookie Manager, and any Cache or DNS manager the plan needs. 3. Check the Authorization Manager the recorder built, and hunt down any `Bearer` header left behind. 4. Name the steps — or re-record with grouping into Transaction Controllers and the Transaction name field driven per step. 5. Correlate: replace server-generated literals with extracted variables. 6. Replay one thread with assertions on, and only then treat it as a plan. Steps 1 to 4 are recording work. Steps 5 and 6 are not — and no recorder setting will do them for you.
- Why does the recorder remove the Cookie header but keep the rest?Because a recorded cookie is a snapshot of one session and would be wrong on the next run. The browser managed cookies during recording; a replay needs an HTTP Cookie Manager to do the same job live. The recorder passes cookies through to the server as it records — it simply refuses to save them into the plan.
- Two identical samplers appeared and the second is greyed out. What happened?Redirect detection. The browser followed a redirect, so both requests were recorded; JMeter saw that the second matched the previous response's Location, disabled it and left comments on both. It assumes the redirect chain arrives uninterrupted, and `proxy.redirect.disabling=false` turns the behaviour off.
- Can the recorder parameterise anything for you while it records?Only known constants. User Defined Variables placed in the target controller, or inside the recorder to override them, cause every occurrence of a variable's value to be written as `${name}` in the recorded samplers. It is case-sensitive, and with Regex matching ticked each value becomes a regex bounded by word boundaries. Values the server generated cannot be handled this way.
A recording is a photograph of one shopping trip. It shows exactly what happened, down to the receipt number and the loyalty card in your pocket — which is why you cannot hand it to someone else and expect them to be able to shop.
saying these in an interview costs you the question
- Treats a recording as a finished test plan
- Assumes the recorded plan keeps its session because the browser did
- Never checks whether a bearer token was hard-coded into the headers
- Reads a 200 response as proof the replay worked
- Keeps every recorded asset sampler because the browser requested it