Run Orchestration

Playwright runs test files in parallel but keeps tests inside a file in order in one worker. Setting fullyParallel true schedules every individual test independently, so tests in the same file can also run at the same time.

Set the reporter config option to an array of entries, each a reporter name plus an options object - for example list, junit with an outputFile, and html. The command line --reporter takes comma-separated names but carries no options.

Playwright re-runs a failing test up to two more times, so retries: 2 allows three runs in all. Only the failing test re-runs, and one that passes on a later attempt is reported as flaky rather than failed.

Playwright splits the selected tests into four disjoint groups and runs only the first. Each shard is an independent run on its own machine, so all four have to be executed before the suite is covered.

The workers option sets how many test processes Playwright runs at once, each running one test at a time. It defaults to half the machine's logical CPU cores, and --workers or -j overrides it for a run.

Each Playwright release pins exact browser builds, and the image ships only those. A mismatched tag leaves the library looking for a browser revision that is not in /ms-playwright, so every test fails at launch.

Playwright's forbidOnly makes a run fail when any test or group is marked with test.only. It stops a focused marker committed by accident from silently shrinking a CI suite to a single test that then reports green.

The tests after the failure are skipped rather than run. A retry does not resume at the failure: the whole group reruns from its first test, because serial mode treats the block as one ordered unit.

Yes. Playwright records a test that failed then passed within its retries as flaky, counts it separately in the report, and still exits with code zero, so the job goes green unless the run is started with --fail-on-flaky-tests.

It changes the unit being split. With fullyParallel off, Playwright shards whole spec files, so one file never spans two shards. With it on, individual tests are sharded, so shards get roughly equal test counts.

Playwright throws the worker away. The process is shut down after the failure and a fresh worker process, with a new browser, picks up the remaining tests, so nothing the failing test left behind reaches them.

In Playwright, --max-failures=N stops the whole run once N tests have failed; the remaining tests never start. The shorthand -x means --max-failures=1, so the run aborts on the first failed test.

Only the default reporter: with CI set and no reporter configured, Playwright prints one character per test instead of the interactive line-per-test output. Everything else people attribute to it is written in the project's own config.

In Playwright, test.fixme() stops the test from running and reports it as skipped rather than failed, so a known-broken payroll test keeps its code and its name in the suite without turning the run red.

Playwright writes a .last-run.json file into the test output directory recording the run status and the ids of failed tests. The --last-failed flag reads that file, so it selects nothing useful if the directory is not preserved.

Default mode opts that scope back out of test-level parallelism. The tests run in declaration order in one worker again, but stay independent: a failure skips nothing after it, and a retry reruns only the failing test.

Steps turn a test into named, timed sections in the report, and a failure is attributed to the step it broke in. Attachments record a named file or string on the test, rendered inline for images and text.

Playwright's list reporter prints one line per test with status and duration, line keeps a single updating line plus failures as they happen, and dot prints one character per test. All three print full failure detail at the end.

testInfo.retry is the zero-based attempt number of the running Playwright test: 0 on the first run, 1 on the first retry, and so on. Hooks read it to reset state or raise logging only when a test is being re-run.

workerIndex names a process and never repeats: every worker a run starts, including replacements after failures, gets a new one. parallelIndex names a slot between zero and workers minus one, and a replacement worker inherits it.

Containers get a private, small /dev/shm, and Chromium passes large buffers through that shared memory. When it fills, renderers die and pages crash. Running with --ipc=host gives the container the host's shared memory instead.

In Playwright, globalTimeout caps wall-clock time for the whole run and ends it whatever the results look like; maxFailures caps how many failed tests the run tolerates. A suite that hangs without failing is stopped only by globalTimeout.

Confirm the schedule is the trigger by rerunning that spec with and without test-level parallelism, then apply the narrowest override that holds: default mode for the file, or a serial describe around only the dependent tests.

The html reporter clears its folder before each run, so the second run replaces the first. Point each run somewhere else with the outputFolder option, or set PLAYWRIGHT_HTML_OUTPUT_DIR per command, and archive each folder separately.

Because on-first-retry starts recording on the second attempt, not the first: the run that actually failed was never traced. Switching to retain-on-first-failure records the original run and keeps it only when it failed.

Have every shard run the blob reporter instead of html. Each writes one archive, CI collects them into a single directory, and npx playwright merge-reports turns that directory into one HTML report covering the whole suite.

The default is half the cores the operating system reports, which is usually the host's, not the container's CPU allowance. Read the worker count from the run header, compare it with the container limit, then pin workers explicitly.

Choose the image when the environment should be pinned and the job needs nothing else; choose your own base plus an install step when it needs other tooling. Often the answer is an image built from the official one.

Playwright treats both identically, so it is a question of ownership. The split belongs to the pipeline launching the jobs, so the --shard flag usually wins; the config option earns its place when a wrapper script starts the run.