Should I have different automated tests for different screen resolutions?

If you have end-to-end tests, keep one set and run it at one width per layout breakpoint, because a responsive page changes structure only at its breakpoints. Add a separate step only where the layout differs, such as a phone menu behind a button.

Which screen sizes should I test a responsive website on?

Test a responsive website at one width inside each range that its CSS breakpoints set, plus the shortest laptop height you support. Fixed-height dialogs break on short screens, not only on narrow ones.

Do I need to test my website on different monitors?

You do not need different monitors to test a website, because a browser lays out a page by viewport size, and a test runner or Chrome device mode can set any viewport. Set the widths your breakpoints use and the shortest height you support.

How do I run the same Playwright tests at several screen sizes?

Define one Playwright project per screen size in playwright.config.ts, each with its own viewport, and every test runs once in each project. Use test.use({ viewport }) when only one file needs another size.

Should I test every screen size?

Verdict

Test it differently

Do not run your tests at every screen size; look at each changed screen at a phone width and a desktop width before merging, and track in analytics the share of visits that finish the main action at each screen width.

Why

Do not test every screen size: check changed pages across widths in review and watch every width in analytics. Blast radius is users, because visitors at the broken width cannot finish their task, and Change frequency is regularly, since layout CSS changes about once a month. Detectability is eventually: a break at a width nobody on the team uses reaches few visitors, who mostly leave without a complaint. Reversibility is trivial, because a reverted stylesheet leaves nothing behind. Test cost is heavy: each extra size multiplies the suite's run time, and each layout needs its own steps. Rule R9 gives Test it differently.

When the decision changes
When	Decision	Why
The key flows already have an end-to-end suite that can run at one width per layout breakpoint, such as 360, 768 and 1280 px	Test minimally: the same end-to-end tests at those three widths, with clicks and no screenshots	Test cost falls to moderate: three fixed widths reuse one set of tests, and a click gives the same result each run
A sticky footer can cover the Pay button on the checkout page at phone widths	Test mandatory: an end-to-end test at the narrowest supported width that clicks the Pay button	Blast radius rises to money and Reversibility to costly: orders lost while the button is covered do not come back
A public-sector contract requires WCAG 2.1 AA, including the Reflow criterion at 320 CSS px wide	Test mandatory: a test on each key page at 320 px wide that asserts the page does not scroll sideways	Blast radius rises to safety-or-legal: the contract turns the Reflow criterion into a legal duty
The layout is an email template that customers open on phones and desktops	Test: screenshot the template with fixed data at a phone and a desktop width, and read each diff in review	Reversibility rises to impossible and Test cost falls to moderate: a sent email cannot be taken back, and fixed data renders the same pixels each run
The screens belong to an internal admin tool that staff open only on office monitors	Do not test other sizes: check each change on the monitor size staff use	Blast radius falls to internal and Detectability to same-day: staff report a broken screen that day

What breaks if you don't test

A new tablet media query lets a long list name push the Add to list button out of its card. The suite runs at 390 and 1280 px, so it passes. Tablet visitors give up, and the first report arrives weeks later, if at all.

What you lose if you over-test

Widths run from 320 px phones to 2560 px monitors. If a suite runs in 6 minutes at one size, ten sizes take 60 minutes on the same CI runners. At phone width the menu hides behind a button, so each navigation step needs a branch per layout. A header redesign then fails at all ten sizes, and the team stops reading the failures.

What to do instead

In analytics, group visits by your breakpoints, and alert when one group's completion rate for the main action falls below the others.
In review, open the changed page in Chrome device mode and drag the width from narrowest to widest.
If the key flows have an end-to-end suite, run it at one width inside each breakpoint range as Playwright projects with the viewport set as in the emulation guide.
Give the laptop project the shortest height you support, because fixed-height dialogs break on short screens.

Procedure and references

When the answer changes

A layout break can hide a button that takes money, such as Pay.
A contract or a law requires WCAG 2.1 AA, including Reflow at 320 px.
The layout leaves the browser, as an email template does.
The key flows already have an end-to-end suite.

Real incident + Code example

The Save button below the fold

On a customer portal I worked on, the suite ran at 390 x 844 and 1280 x 720. A redesign gave the Edit profile dialog a fixed height of 680 px. On 1366 x 768 laptops, browser toolbars and the taskbar leave a viewport about 630 px tall, so Save sat below the visible area of a dialog that did not scroll. Three weeks later a support agent saw it on a customer's shared screen. We added one short-laptop project, not a device list:

// playwright.config.ts: one project per layout, not per device
import { defineConfig } from '@playwright/test';
export default defineConfig({
  projects: [
    { name: 'phone', use: { viewport: { width: 360, height: 640 } } },
    { name: 'tablet', use: { viewport: { width: 768, height: 1024 } } },
    // the shortest laptop screen we support
    { name: 'laptop', use: { viewport: { width: 1366, height: 630 } } },
  ],
});

// profile.spec.ts: runs once in each project
import { test, expect } from '@playwright/test';
test('Save is reachable in the profile dialog', async ({ page }) => {
  await page.goto('/profile');
  await page.getByRole('button', { name: 'Edit profile' }).click();
  // click() fails when the button stays outside the viewport
  await page.getByRole('button', { name: 'Save' }).click();
  await expect(page.getByText('Profile saved')).toBeVisible();
});

Sources

Should I test CSS?No
Is visual regression testing worth it?No
Should I test in every browser?Test it differently
Is automated UI testing worth it?Yes
Should I test accessibility with automated tools?Yes

FAQ

Should I have different automated tests for different screen resolutions?: If you have end-to-end tests, keep one set and run it at one width per layout breakpoint, because a responsive page changes structure only at its breakpoints. Add a separate step only where the layout differs, such as a phone menu behind a button.
Which screen sizes should I test a responsive website on?: Test a responsive website at one width inside each range that its CSS breakpoints set, plus the shortest laptop height you support. Fixed-height dialogs break on short screens, not only on narrow ones.
Do I need to test my website on different monitors?: You do not need different monitors to test a website, because a browser lays out a page by viewport size, and a test runner or Chrome device mode can set any viewport. Set the widths your breakpoints use and the shortest height you support.
How do I run the same Playwright tests at several screen sizes?: Define one Playwright project per screen size in playwright.config.ts, each with its own viewport, and every test runs once in each project. Use test.use({ viewport }) when only one file needs another size.