20 Playwright Projects and Configuration Interview Scenarios

Configuration questions become senior when every added project has a cost and every missing boundary can contaminate an entire run. The candidate must turn browser, device, environment, role, and test-subset requirements into a matrix that produces distinct evidence without multiplying duplicate work.

The scenarios below focus on design defense. Explain what belongs in the root config, what belongs in a project, how setup and teardown are observed, and how a developer can reproduce one CI lane locally. A correct API name is useful; a coherent execution model is the actual answer.

Build the Configuration Argument

Playwright's configuration guide separates top-level runner controls from shared use options, while projects apply named configurations to logical groups. Start every answer with a concrete coverage requirement, choose the narrowest configuration boundary, and finish with the command and report that will prove it works.

The best answers also identify a non-goal. A project created only because the tool supports another combination adds runtime and report noise without improving confidence.

Root Config and Environment Boundaries

1. Why should baseURL usually be configured instead of concatenated in tests?

Configuring baseURL lets tests navigate with application-relative paths and keeps the deployment address outside scenario logic. A project can override it for an intentional environment lane. I would still validate the URL before building the config and prevent production targets for destructive suites. Concatenating strings throughout tests creates inconsistent slash handling, scattered environment reads, and reports that are harder to reproduce.

2. How would you validate a target environment before Playwright starts collecting tests?

I would parse the environment name and required URL in a small typed function imported by the config. Unknown names, missing values, non-HTTPS remote targets, or prohibited destructive combinations should throw immediately without printing credentials. This turns a late navigation failure into a clear configuration error and gives every project the same normalized input.

type EnvironmentName = 'local' | 'staging'

function readEnvironment(): { name: EnvironmentName; baseURL: string } {
  const name = process.env.TEST_ENV ?? 'local'
  if (name !== 'local' && name !== 'staging') {
    throw new Error(`Unsupported TEST_ENV: ${name}`)
  }

  const baseURL = name === 'local'
    ? 'http://127.0.0.1:3000'
    : process.env.STAGING_BASE_URL

  if (!baseURL) throw new Error('STAGING_BASE_URL is required')
  return { name, baseURL }
}

3. Why are retries and workers reasonable top-level policies with CI overrides?

They describe runner behavior across projects unless a project has a specific reason to differ. CI may use retries to collect evidence for intermittent failures and a worker count suited to shared infrastructure, while local runs favor fast feedback. I would not use retries to redefine pass criteria; flaky outcomes must stay visible. Any project override should be tied to a documented risk, not copied without explanation.

4. How would you keep secrets out of configuration diagnostics?

I would validate the presence of secret variables but never interpolate their values into errors, project names, annotations, or reporter metadata. Tests receive secrets through controlled fixtures or request headers, not public metadata. Traces and storage-state files need protected artifact handling. A useful error names the missing variable and target environment; it does not dump the environment object for convenience.

Project Matrix and Device Coverage

5. Why is one project per browser not a complete matrix strategy?

Browser engines address rendering and platform behavior, but risk may also come from viewport, touch input, locale, permissions, role, or environment. Conversely, crossing every dimension creates many redundant runs. I would identify which combinations can expose distinct defects, keep a small pull-request matrix, and schedule broader coverage separately. The project name should communicate the selected combination and why it exists.

6. How would you prevent browser, device, and environment combinations from exploding?

I would create a risk table before code. Core journeys may run on each engine against one stable environment; responsive journeys may use representative desktop and mobile profiles on one engine; a production smoke lane may use one conservative browser. Orthogonal concerns should remain separate unless their interaction is risky. I would review failure history periodically and remove projects that never provide unique information.

7. Why does property order matter when overriding a device descriptor?

A device descriptor includes several context options, including viewport and user agent. If a custom viewport is placed before the spread, the descriptor can overwrite it. I would spread the selected device first and put deliberate overrides afterward, then verify the effective project settings in a focused test. The answer should also acknowledge that emulation approximates configured behavior; it does not turn desktop hardware into a physical phone.

8. How should project names support local reproduction and reports?

Names should be stable, concise, and map to a meaningful lane such as webkit-desktop or chromium-mobile-checkout. A developer should be able to copy the name into --project and reproduce the configuration. I would avoid secrets, generated URLs, or volatile build labels in names. Detailed environment context can be attached safely elsewhere, while the name remains a durable filtering contract.

Test Selection and Project Responsibilities

9. When would you use testMatch instead of a tag filter?

testMatch fits a durable file-level responsibility, such as setup files or a package-specific suite. Tags fit scenario attributes that cut across directories, such as smoke or destructive behavior. I would avoid maintaining the same classification in both paths and tags because they drift. The choice should make collection predictable and let a reviewer understand why a test belongs to a project without running it.

10. How would you keep a mobile-only test from running in desktop projects?

I would first ask whether the behavior is truly mobile-only or simply responsive. For a real device-specific scenario, use a clear test file boundary or an annotation consumed by project filtering. I would not branch extensively inside one test based on project name, because that creates several hidden scenarios under one title. Separate expectations produce clearer reports and make missing coverage visible.

11. Why is branching on testInfo.project.name often a design smell?

Project name is useful for reporting or a narrow, intentional variation, but large conditional blocks mean one test contains multiple behaviors. I would prefer project use options, typed fixture options, or separate tests for materially different outcomes. If the only difference is expected copy or a small supported capability, a typed project parameter can remain readable. The branch must express domain configuration, not parse naming conventions.

12. How would you design separate smoke and regression projects without duplicate accidental execution?

I would define mutually understandable selection rules and verify collection with --list. A smoke project may match dedicated smoke files or tags, while the regression project explicitly excludes that set if duplicate execution has no value. Shared top-level options remain shared. I would document whether smoke tests intentionally run again in the broad lane, because silent overlap wastes time and distorts result counts.

Dependencies, Setup, and Teardown

13. Why are project dependencies often preferable to globalSetup for authentication?

Dependency setup runs as tests, so it can use fixtures, appear in HTML reports, and produce traces. Dependent projects start only after the setup project passes. That observability is valuable for login failures. A global setup function may still suit process initialization that does not need test-level reporting, but the candidate should state the tradeoff rather than using it as an invisible default.

14. What should happen when a setup dependency fails?

Projects that depend on the failed setup should not run, because their prerequisite is unproven. The setup report should identify the failed operation and retain safe artifacts. I would resist adding fallback behavior that lets dependent tests fail hundreds of times at navigation or authentication. A single precise setup failure is more actionable than a flood of downstream symptoms, and rerunning the dependency should be straightforward.

15. How would you configure observable setup and teardown projects?

I would give setup and cleanup dedicated test files, connect the setup project's teardown to cleanup, and make browser projects depend on setup. Cleanup must handle partial setup and should use an external run identifier rather than mutable test order. The setup and teardown guidance is the reference for this lifecycle.

export default defineConfig({
  projects: [
    { name: 'cleanup', testMatch: /environment\.teardown\.ts/ },
    {
      name: 'setup',
      testMatch: /environment\.setup\.ts/,
      teardown: 'cleanup',
    },
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
      dependencies: ['setup'],
    },
  ],
})

16. When is --no-deps useful, and what risk does it introduce?

It is useful for focused debugging when the prerequisite already exists or the developer intentionally wants only the selected project. It skips dependencies and teardown, so the run may use stale state or leak resources. I would treat it as an explicit diagnostic mode, never the normal CI command, and state what prerequisite was established manually before trusting the result.

CI Execution and Failure Analysis

17. How should sharding interact with project dependencies?

I would understand whether each shard executes the selected dependency work and ensure setup is safe under that topology. Shared external initialization needs idempotency or a lease, while shard-specific data needs unique namespaces. I would not assume a setup project globally runs once across machines. The CI design should record shard and project identifiers so collisions and repeated cleanup can be traced.

18. Why can shared output paths corrupt a multi-project run?

Projects and workers may produce artifacts concurrently. Custom screenshots, downloads, or state files written to one fixed filename can overwrite each other. I would use Playwright-provided per-test output paths or include stable project, worker, and test identity in custom locations. Authentication state intentionally shared by projects needs a setup owner and atomic creation, not opportunistic writes from every test.

19. How would you diagnose a test that passes locally but fails only in one project?

I would reproduce with that exact --project name, compare its effective use options, and inspect the trace for viewport, locale, browser, permissions, base URL, and stored state. Then I would determine whether the project exposed a real compatibility defect or inherited an unintended override. Running all projects locally can hide the relevant artifact among noise; focused reproduction preserves the failing boundary.

20. How would you review a config file with dozens of nearly identical projects?

I would build a table of dimensions and risk ownership, identify accidental Cartesian products, and compare each project for unique behavior. Repeated configuration can be generated from small typed data only if that improves reviewability and preserves stable names. I would remove unsupported combinations, separate pull-request and scheduled lanes, and add a collection check. The goal is legible coverage, not the shortest config file.

Configuration Review Checklist

• Validate environment names, URLs, and required variables before test collection.
• Keep project combinations tied to explicit product or platform risks.
• Put shared context options in use and intentional exceptions in named projects.
• Make setup and teardown visible when their failures need traces and reports.
• Confirm project selection and overlap with the list command.
• Give every CI lane a local reproduction command.
• Namespace all custom artifacts and mutable external data.

Conclusion: Make Every Project Earn Its Run

A credible Playwright configuration is a coverage model expressed as code. Every project should expose a distinct risk, every dependency should make prerequisites observable, and every environment input should fail safely before collection. Resist matrix growth that cannot be defended, preserve one-command reproduction, and design reports so the failing configuration is obvious. That is the configuration judgment a senior SDET is expected to bring.