Playwright POM: 5 anti-patterns that get expensive

A page object model does not make a suite stable. It localises change. When the POM is wrong, every screen change breaks ten specs instead of one.

These are the five gaps I see most often, and what they actually cost.

1. new LoginPage(page) inside the spec

The page is built by hand in the test. test.extend() fixtures stop doing anything useful: no shared setup, no isolated worker, and every spec reinvents the wiring.

Fix. Declare the pages in fixtures/test.fixture.ts and receive them as test arguments.

2. Locators live in the spec

page.locator('.inventory_item') next to the scenario couples the test to the DOM. On the next class change, you search the string across the whole tests/ folder.

Fix. getByRole or getByTestId inside the page object. The spec only talks about business actions.

3. nth() with no filter

locator.nth(5) depends on DOM order. A banner, an ad, one extra row, and the test clicks somewhere else. That is an intermittent failure dressed up as a selector.

Fix. .filter({ hasText }), or a stable test id.

4. No final assertion

The test clicks, fills, and ends. An error screen goes green. Playwright cannot retry an assertion that does not exist.

Fix. A web-first assertion at the end of the flow, or an expectXxx() method on the page object.

5. No tags

Thirty-five scenarios with no @smoke, @critical, or @regression. You cannot run a subset before a release. CI runs everything, or nothing.

Fix. A short convention, applied in the test title. The grep filter becomes a tool, not a wish.

Where to start

If the suite already exists, do not rewrite the page objects in one go. An Audit Flash (€490, 48 hours) names the occurrences and the order. You fix them afterwards, or you scope a Stabilization Sprint.

If you do not have a suite yet, hand-building the POM for three months is the expensive path. Test Architect Setup delivers the structure, the fixtures, and CI. You keep ownership.