Practice Hub
Score: 0 / 12

Playwright Configuration

12 challenges covering playwright.config.ts options, CLI flags, reporters, sharding and project setup.

Challenge 1BeginnerConfig Options
Solved
What does testDir control?
What is the purpose of the testDir option in playwright.config.ts?
export default defineConfig({
  testDir: './tests',
});
Answer: B — root directory for test file discovery
testDir tells Playwright which directory to search for test files. Combined with testMatch (default: **/*.{spec,test}.{ts,js}), it controls exactly which files Playwright considers to be tests. It defaults to the directory of the config file. Test output (reports, screenshots) goes to outputDir (default: test-results/).
testDir = where to find tests. Think of it as "where are my .spec.ts files?"
Challenge 2IntermediateProjects
Solved
What does the projects array enable?
What is the main purpose of defining multiple entries in the projects array?
export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox',  use: { ...devices['Desktop Firefox'] } },
    { name: 'mobile',   use: { ...devices['iPhone 12'] } },
  ],
});
Answer: B — same tests, different browser/device/config combinations
Each project entry defines a named configuration with a use object — typically different browsers, device viewports, or locale settings. Playwright runs all tests under each project, producing cross-browser coverage from a single test suite. Projects can also set different testDir, testMatch, or fixture overrides for specialized subsets of tests.
Projects = "run these tests N times, each with a different config." Cross-browser testing made easy.
Challenge 3IntermediateParallelism
Solved
What does fullyParallel: true change?
By default, tests within a file run sequentially. What does fullyParallel: true do?
Answer: B — individual tests within a file run across workers
By default, Playwright parallelizes at the file level — files run in parallel but tests within a file run sequentially in one worker. fullyParallel: true enables test-level parallelism: each individual test can run in any worker, regardless of which file it's in. This maximizes throughput but may break tests that share state within a describe block (e.g., tests that depend on beforeAll setup).
Default = file-level parallelism. fullyParallel = test-level parallelism. Great for speed, but be careful with shared state.
Challenge 4BeginnerRetries
Solved
What does retries: 2 mean in config?
You set retries: 2. A test fails on its first run. What happens next?
Answer: B — up to 2 retries after the first failure
retries: 2 means each test gets up to 2 additional attempts after a failure — 3 total runs (1 original + 2 retries). A test is marked as flaky if it passes on a retry after failing. It's only marked as fully failed if all attempts fail. Retries are useful in CI for handling transient network issues but shouldn't mask real bugs — keep retries: 0 locally during development.
retries: 2 = 2 extra attempts. Total runs = 1 + retries. A test needs to fail all attempts to be reported as failed.
Challenge 5BeginnerCLI Flags
Solved
What does the --headed CLI flag do?
What is the effect of running npx playwright test --headed?
Answer: B — browser runs with a visible window
By default, Playwright runs browsers in headless mode (no visible window) for speed and CI compatibility. The --headed flag opens a real, visible browser window during test execution. This is useful for debugging tests visually. You can also set use: { headless: false } in config. The equivalent of --headed in config is use: { headless: false }.
"Headed" = the browser has a visible head (window). "Headless" = no window, runs invisibly. Use --headed to see what's happening during debugging.
Challenge 6BeginnerCLI Flags
Solved
What does --project=chromium filter?
You have 3 projects: chromium, firefox, webkit. You run npx playwright test --project=chromium. What runs?
Answer: B — only the named project runs
--project=chromium filters test execution to only the project named "chromium". Firefox and webkit are skipped. You can pass multiple project names: --project=chromium --project=firefox. Project names are case-sensitive and must match the name field in the projects array of your config. Very useful for fast local development targeting a single browser.
--project filters by the project's name field in config. Only that project runs; all others are skipped.
Challenge 7IntermediateReporters
Solved
Where does the HTML reporter save its output?
You configure reporter: [['html']]. Where is the report created and how do you open it?
export default defineConfig({
  reporter: [['html'], ['list']],
});
Answer: B — playwright-report/ folder, open with show-report
The HTML reporter creates a self-contained report at playwright-report/index.html by default. Run npx playwright show-report to serve it locally and open it in a browser. The report includes test results, traces, screenshots, and video recordings attached to each test. You can customize the output directory: [['html', { outputFolder: 'my-report' }]].
HTML report → playwright-report/. Open it with npx playwright show-report. Different from test-results/ which stores artifacts.
Challenge 8AdvancedCI / Sharding
Solved
What does --shard 1/3 do?
You run npx playwright test --shard 1/3 on the first CI machine, --shard 2/3 on the second, --shard 3/3 on the third. What is the effect?
Answer: B — splits the suite across parallel CI machines
Sharding distributes tests evenly across N CI machines. --shard 1/3 runs the first ~1/3 of tests, 2/3 runs the next third, and 3/3 runs the final third. All 3 machines run in parallel, reducing total CI time by ~3x. You collect and merge the HTML reports afterwards using npx playwright merge-reports. This is the standard pattern for large test suites in CI pipelines.
--shard X/N = "run the X-th of N equal slices." Use across N parallel CI machines to parallelize your suite.
Challenge 9BeginnerConfig Options
Solved
What does testMatch control?
You set testMatch: ['**/*.spec.ts']. What is the effect?
Answer: B — glob pattern for test file names
testMatch is a glob (or array of globs) that controls which files Playwright treats as test files. The default is ['**/*.{spec,test}.{ts,js,mjs,cjs}']. Setting ['**/*.spec.ts'] means only TypeScript files ending in .spec.ts are treated as tests — JavaScript test files would be ignored. Useful for monorepos or mixed codebases.
testMatch = file name pattern. It's a glob that decides which files are tests, not which test cases inside them.
Challenge 10IntermediateArtifacts
Solved
What does use.screenshot: 'only-on-failure' do?
You configure use: { screenshot: 'only-on-failure' }. What is the behaviour?
export default defineConfig({
  use: {
    screenshot: 'only-on-failure',
    // also: 'off' | 'on'
  },
});
Answer: B — automatic screenshot on test failure only
screenshot: 'only-on-failure' tells Playwright to automatically capture a full-page screenshot when a test fails, and attach it to the HTML report. Options: 'off' (no automatic screenshots), 'on' (screenshot after every test regardless), 'only-on-failure' (only on fail). Screenshots appear in the HTML report under the failed test. The file is saved in test-results/.
Think of it as "take a crime scene photo." Playwright only captures automatically when something goes wrong — very useful for CI debugging.
Challenge 11AdvancedwebServer
Solved
What does the webServer option do?
You configure webServer in your config. What does Playwright do with it before running tests?
export default defineConfig({
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
});
Answer: B — starts the dev server and waits until ready
webServer automatically runs your dev server (command) before tests start and waits until the url responds with a successful HTTP response. Tests won't start until the server is up. After all tests finish, Playwright shuts down the server. reuseExistingServer skips starting a new server if one is already listening — handy locally but should be false in CI for reproducibility.
webServer = "start my app first, then run tests." Playwright waits for the URL to be reachable before the first test starts.
Challenge 12IntermediateArtifacts
Solved
When is video recorded with 'on-first-retry'?
You configure use: { video: 'on-first-retry' }. When is a video recording made?
Answer: B — recorded on the first retry of a failing test
video: 'on-first-retry' records video only when a test is retried for the first time — meaning the original run failed. This balances performance (no video overhead for passing tests) with debuggability (you get a recording of the failure reproduction). Options: 'off', 'on' (always), 'retain-on-failure' (records always, deletes on pass), 'on-first-retry'.
"on-first-retry" = the test already failed once and is being retried. Record that run. You skip the overhead for passing tests.