Running on Chromium, Firefox and WebKit

Playwright ships with three browser engines, and running your suite on all of them is a few lines of config. That makes the mechanics easy and moves the real question elsewhere: should you?

The mechanics first.

export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox',  use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit',   use: { ...devices['Desktop Safari'] } },
  ],
});

Now npx playwright test runs the whole suite three times, once per engine. Run one with --project=chromium.

The three engines are the ones that matter, and it is worth knowing what they represent. Chromium covers Chrome and Edge. Firefox is Gecko. WebKit is the engine behind Safari, which is the one people forget and the one that behaves differently most often. If your users are on iPhones, every browser they can use is WebKit underneath.

You can also emulate devices:

{ name: 'mobile-safari', use: { ...devices['iPhone 13'] } },

That sets the viewport size, the user agent and touch support. It is real enough to catch layout and touch problems. It is not a real iPhone: no real network conditions, no real hardware, no App Store browser quirks. Say that plainly if an interviewer asks.

Now the judgement, which is what separates a mid-level engineer from someone who copied a config.

Three browsers is three times the runtime. A twelve-minute suite becomes thirty-six. On every commit, that is the difference between a team that waits for tests and a team that ignores them.

The arrangement most teams settle on:

• Every commit: one browser, usually Chromium. Fast feedback.
• Nightly, or before release: all three, plus device emulation.

Cross-browser bugs are rarer than people expect, and they cluster. Layout and CSS differences, date and number formatting, video and audio, and anything using a very new web feature. Business logic almost never differs, because it is the same JavaScript.

So the honest advice: run your smoke tests everywhere and your full suite on one browser. A failure in login on WebKit matters enormously. A failure in the eleventh variation of a settings form on WebKit usually means your test is fragile, not that Safari is broken.

One practical note. When a test fails on only one engine, read the trace from that project before assuming a browser bug. In my experience most single-browser failures turn out to be timing: that engine renders slightly slower or faster, and the test had a hidden race all along. The browser did not break your test, it exposed it.

Remember this: smoke tests on all three, the full suite on one, and treat a single-browser failure as a timing suspect first.

Reference: Browsers.