What do Playwright's `list`, `line` and `dot` terminal reporters each print to the console?

## Three renderings of the same events `list`, `line` and `dot` are Playwright's terminal reporters. They subscribe to identical events and differ only in how much they print while the run is in progress; none of them changes what is considered a failure, and all three print the same detailed failure blocks. Choosing between them is a decision about log volume, not about information loss. ## `list` — one line per test The `list` reporter prints a line for each test, carrying its title and, once finished, its status and duration. In an interactive terminal the in-progress lines are updated in place; in a plain CI log each finished test lands as its own line, which makes the log greppable by test title later. It is the default when you run Playwright locally, and it is the only one of the three with a notable option: `printSteps: true` expands each test into its `test.step` titles as they execute. - The title is printed with the test's file and project, so a failure is attributable at a glance. - Finished lines carry the duration, which is the cheapest way to spot a payroll test that has started creeping past its budget. - The log stays searchable: `grep 'reconciles to the ledger'` finds the run that covered it. - The cost is one line per test, which for a few thousand payroll cases is most of the job log. ## `line` — one line for the whole run The `line` reporter keeps a single continuously rewritten line showing progress and the test that just finished, and prints failures above it as they happen. For a payroll suite of a few thousand cases this is the compromise choice: you still see failures the moment they occur, without paying a line of log per test. ## `dot` — one character per test The `dot` reporter emits a single character per finished test, so a very large run compresses into a handful of lines, with all failure detail printed in the summary at the end. It is the cheapest option for a log that is stored and rarely read line by line. | Reporter | Output volume for 500 tests | While it runs you see | Best for | | --- | --- | --- | --- | | `list` | ~500 lines | every test title and result | local runs, greppable CI logs | | `line` | a few lines plus failures | progress counter and failures | long runs where noise costs | | `dot` | a few lines | a character trail | very large suites, archived logs | ## The failure output does not shrink This is the part people get wrong when they switch to `dot` to quiet a noisy job: the summary is unchanged. All three reporters print the failing test's title path, the error and the snippet of source around it, plus the list of attachments recorded for that test. Quietening progress output does not cost you diagnosis material. ## Picking one for a payroll pipeline - Running a handful of specs on your own machine: `list`, and add `printSteps` when you are debugging a long test's structure. - A local full-suite run you glance at occasionally: `line`. - A CI job whose log is mostly scrolled past: `dot`, with an HTML or JUnit artifact carrying the detail. - A CI job whose log gets searched for a test name during triage: `list`, because each title appears on its own line. Because terminal reporters all write to stdout, list exactly one of them in the `reporter` array and let file-writing reporters carry everything else: ```ts export default defineConfig({ reporter: [ ['dot'], ['html', { open: 'never' }], ], }); ``` Swapping `dot` for `list` in that array is a one-word change, so it is worth trying both against a real job log rather than arguing about it.