skip to content

Your team debugs every Playwright failure by re-running headed with slowMo. What would you change?

level: principalimportance: should knowfreq 30%

answer

  1. A launch option, not a command-line flag
  2. It slows every operation, not one
  3. One real-time look, nothing kept
  4. A delay perturbs what you measure
  5. Right for showing, wrong for diagnosing

basics

~20 s

Make UI mode the default local loop and keep headed plus slowMo for the rare interaction you must watch in real time. Slowing every action changes timing, costs wall-clock minutes per look, and leaves no record to re-examine.

solid answer

~50 s

Watching a slowed headed run is the weakest of Playwright's debugging surfaces. `slowMo` is a `launchOptions` field, not a command-line flag, and it delays **every** operation uniformly, so a two-minute spec becomes fifteen and you get exactly one real-time look per run with nothing kept afterwards. Worse, it perturbs the very timing you may be investigating. I would standardise the ladder instead: **UI mode** as the everyday loop, because it keeps each action's before-and-after DOM and re-runs on save; **`--debug` or `page.pause()`** when you need to stop on one line and poke at the live page; **`DEBUG=pw:api`** when there is no window to open, such as a container or a build agent. Headed with `slowMo` keeps a narrow place - demonstrating a flow to someone, or watching a drag or animation that only makes sense at speed - and should be an opt-in environment variable, defaulting to zero.

code

typescript · 10 lines
typescript
import { defineConfig } from '@playwright/test';

export default defineConfig({
  use: {
    // opt-in: PW_SLOW_MO=250 npx playwright test --headed tests/driver-map.spec.ts
    launchOptions: {
      slowMo: Number(process.env.PW_SLOW_MO ?? 0),
    },
  },
});

go deeper

for a junior

Know that slowMo is a browser launch option set in the Playwright config rather than a flag you type, and that it slows the whole run rather than the one step you care about.

for a middle

Explain the concrete costs - uniform delay, one look per run, no record kept - and that inserting a delay before every operation can change the timing behaviour you are trying to observe.

for a senior

Match the surface to the question: UI mode for the everyday loop, --debug or page.pause for one live moment, DEBUG=pw:api where no window can open, headed slowMo for showing rather than diagnosing.

for a principal

Own the default. Pick the team's debugging ladder, keep slowMo opt-in and zero by default, and justify the choice in engineering time saved and in evidence that survives the run.

Re-running headed with `slowMo` is the first debugging move most people learn, and it is a reasonable one for a first look. As a *team default* it quietly costs a great deal. ## What the habit actually buys Real value, and it is worth naming before criticising it: you see the application as a user would, at a pace a human can follow, and some failures are obvious on sight - the modal that never opens, the empty order list, the page that never navigated. For a flow that is fundamentally visual, nothing else is as direct. It is worth knowing how it is configured, because the mechanics point at the problem. `slowMo` is a **browser launch option**, not a `playwright test` flag: you set it through `launchOptions` in the Playwright config, or per-project with `test.use`. It applies to the whole run, uniformly, at whatever value you hard-code. ## Where it falls down - **It is uniform.** The delay is applied to every operation, not just the interesting one. A spec that took two minutes takes fifteen, and you spend fourteen of them watching setup you already understand. - **One look per run.** Miss the moment and you re-run the whole thing. There is no scrubbing back. - **It leaves no record.** When the window closes you have nothing to share with a colleague, attach to a ticket, or look at again tomorrow. - **It changes timing.** Inserting a delay before every operation can make a race disappear, or create one. Debugging with a tool that perturbs the thing you are measuring is a poor default. - **It hides internal state.** Watching the page never tells you which actionability check an action was failing, or what a locator resolved to. - **It scales badly.** Multiply "re-run the spec slowly" by a team and by every failure, and it becomes a real share of engineering time. ## The ladder I would standardise on 1. **UI mode** (`npx playwright test --ui`) as the default local loop: a clickable test list, watch mode on save, an action list with the DOM before and after each step, and Pick locator for selector work. Most failures end here. 2. **`--debug` or a temporary `page.pause()`** when you need the *live* page at one specific moment - to click something yourself, or to try a locator against real state. 3. **`DEBUG=pw:api`** when no window can open - a container, an SSH session, a build agent - or when the question is specifically "which check was this action still failing?". 4. **Headed with `slowMo`** last, for the narrow cases below. ## Where headed and slowMo still earn their place - Demonstrating a flow to a product owner or a new joiner, where the point is that a human can follow it. - Watching a drag, an animation or a live-updating surface - the driver map on a food-delivery order tracker - where the failure is about motion and only makes sense at speed. - A first, cheap orientation on an unfamiliar suite, before you know what you are looking for. Note what these have in common: they are about *communication and orientation*, not diagnosis. ## Making it a standard rather than an opinion | Situation | Reach for | Why | |---|---|---| | Writing or fixing a test locally | UI mode | fastest loop, keeps evidence, no code edit | | One suspect line in a long test | `page.pause()` under `--debug` | live page exactly where you need it | | No display available | `DEBUG=pw:api` | logging only, changes nothing | | Explaining a flow to a person | headed with `slowMo` | a human can follow it | Two changes make the ladder stick: - Put `slowMo` behind an opt-in environment variable that defaults to zero, so nobody ships a slowed suite by accident and nobody has to edit the config to use it. - Write the ladder into the repository's testing README and demonstrate UI mode once in a team session. Habits move when someone watches a colleague solve a real failure in thirty seconds. ## The judgment being tested The underlying point is not that `slowMo` is bad. It is that a team's default debugging surface is an engineering decision with a measurable cost, and choosing "watch it slowly" by default trades minutes of machine time and lost evidence for a tool that answers fewer questions than the ones sitting next to it.

  • How is slowMo configured for a playwright test run, and why does that matter here?
    It is a browser `launchOptions` field, set in the config or through `test.use` - there is no command-line flag for it. That matters because using it means editing shared configuration, which is why teams hard-code a value and forget it. Reading it from an environment variable keeps the default at zero.
  • When would you still tell someone to re-run headed with slowMo?
    When the point is to watch rather than to diagnose: showing a flow to a colleague, or investigating a drag, animation or live-updating view where the failure is about motion. Also as a cheap first orientation on a suite you have never seen, before you know what to look for.
  • What is the strongest argument against slowMo as a default diagnostic?
    It changes the timing of the run. Adding a delay before every operation can hide a race or create one, so the run you are watching is not the run that failed. A surface that records what happened without altering it answers the same questions more honestly.

saying these in an interview costs you the question

  • Treats slowMo as a command-line flag on playwright test
  • Says slowing the run makes tests more reliable
  • Leaves a non-zero slowMo committed in the shared config
  • Believes watching the browser reveals actionability failures
  • Thinks slowMo delays only the action that is failing
  • Uses a slowed headed run as the only debugging surface