skip to content

In a Playwright script, when would you use tracing.startChunk() instead of tracing.start()?

level: seniorimportance: nice to knowfreq 28%

answer

  1. One recording, several exported pieces
  2. Start once, then bracket each phase
  3. Each closing call writes its own file
  4. Rarely needed under the test runner

basics

~10 s

Use chunks when one long-lived browser context should produce several separate trace zips. Tracing is started once on the context, then each startChunk and stopChunk pair records and exports one segment of the session.

solid answer

~40 s

`context.tracing.start()` begins recording for a context; `startChunk()` slices that recording into separately exported pieces. The pattern is: call `start()` once with your content options, then wrap each phase in `startChunk({ title })` and `stopChunk({ path })`, which writes that phase's own zip. It matters when a context is expensive to build and reused across many logical scenarios — a signed-in session against an order tracker that walks checkout, then live status, then the driver map. Without chunks you get one enormous zip covering everything; with them each scenario gets a small, individually openable archive. The chunk API is a library-mode tool: under the test runner each test already gets its own trace boundary, so you rarely need it there.

code

typescript · 14 lines
typescript
const context = await browser.newContext({ storageState: 'customer.json' });
await context.tracing.start({ screenshots: true, snapshots: true });
const page = await context.newPage();

await context.tracing.startChunk({ title: 'live status' });
await page.goto('https://orders.example.com/track/9182');
await page.getByText('Preparing your order').waitFor();
await context.tracing.stopChunk({ path: 'traces/live-status.zip' });

await context.tracing.startChunk({ title: 'driver map' });
await page.getByRole('tab', { name: 'Driver' }).click();
await context.tracing.stopChunk({ path: 'traces/driver-map.zip' });

await context.tracing.stop();

go deeper

for a junior

Know that a plain start and stop pair is enough for a simple script, and that chunks exist for splitting one long session into several files.

for a middle

Explain the ordering rule that tracing must be started before a chunk opens, and that the content options are fixed at start rather than per chunk.

for a senior

Show judgment about segmentation: which phases of an expensive reused session deserve their own archive, and when to discard a chunk by omitting its path.

for a principal

Own the boundary between library-mode scripting and the runner, so teams do not hand-roll segmentation the runner already provides per test.

`context.tracing.start()` and `context.tracing.stop()` bracket a whole recording. `startChunk()` and `stopChunk()` bracket a **segment** of one recording that is exported on its own. The distinction only matters when a single browser context outlives the thing you want a trace of. ## The mechanics 1. `await context.tracing.start({ screenshots: true, snapshots: true, sources: true })` — begins tracing on the context and fixes the content options for everything that follows. 2. `await context.tracing.startChunk({ title: 'live status' })` — opens a segment. 3. Drive the scenario. 4. `await context.tracing.stopChunk({ path: 'traces/live-status.zip' })` — closes the segment and writes that zip. 5. Repeat steps 2-4 for each further scenario. 6. `await context.tracing.stop()` — ends tracing on the context entirely. The order is load-bearing: `startChunk()` requires tracing to have been started already. Chunks do not nest, and `stopChunk({ path })` without a path ends the segment without exporting it, which is how you deliberately discard an uninteresting phase. ## What it buys you - **One zip per scenario instead of one per session.** A trace of a two-hour session is unwieldy; a trace of one checkout is not. - **Selective export.** Record the whole session, but export only the phases that matter — omit the path on the chunks you do not want. - **Named segments.** `title` labels each chunk, so a folder of exports is readable without opening them. - **No repeated setup.** The context, its cookies and its storage state survive across chunks, because tracing never actually stopped. ## Where it fits, and where it does not | situation | use | |---|---| | library script, one context, many scenarios | `start()` once, a chunk per scenario | | library script, one context, one scenario | plain `start()` / `stop({ path })` | | test runner with a `trace` mode set | neither — the runner manages tracing per test | That last row is the one candidates get wrong. Under the test runner, each test already has its own recording boundary and its own zip, so reaching for chunks inside a test both duplicates the runner's job and fights it for control of the same context's tracing. ## A worked shape For a food-delivery order tracker driven by a long-lived signed-in context, the natural segmentation is by user journey: place an order, watch live status, follow the driver map. Each is a chunk; each produces its own archive named for the journey. When the status phase breaks, you open one small zip rather than scrubbing a timeline that starts an hour earlier. ## Practical cautions - Content options belong on `start()`, not on the chunk — a chunk cannot turn snapshots back on if the recording was started without them. - Give every exported chunk a distinct path, or a later export will overwrite an earlier one. - Remember that everything between chunks is still being recorded by the underlying session; chunks control **export boundaries**, not whether the browser is being observed. - Close the recording with `stop()` when the context's work is done, so buffered data is released rather than growing for the life of a long-running script. ## The interview answer Say what the two API pairs bracket — a recording versus a segment of one — then give the concrete reason chunks exist: an expensive context reused across scenarios that each deserve their own evidence file. Finishing with "and under the test runner you would not need this" shows you know which mode of the tool you are in.

  • What happens if you call stopChunk() without a path?
    The segment ends and nothing is exported. That is the deliberate way to discard a phase you do not care about while keeping the session's recording alive for the chunks that follow — useful for skipping expensive setup navigation that would otherwise bloat every archive.
  • Why is the chunk API rarely the right tool inside a test-runner suite?
    Because the runner already brackets tracing per test according to the trace mode, giving each test its own zip. Adding chunks inside a test duplicates that boundary and contends with the runner for the same context's tracing. If you want finer segments there, the answer is usually smaller tests, not manual chunking.

saying these in an interview costs you the question

  • Calls startChunk without starting tracing first
  • Expects nested chunks to work
  • Sets screenshots or snapshots on the chunk instead
  • Thinks chunks append into one archive
  • Uses chunks inside runner tests that already trace