Question 1

How would you structure a framework from scratch? Talk at the folder level.

Accepted Answer

Roughly: tests/ — specs grouped by feature, scenario logic only; pages/ — POMs and component objects; fixtures/ — test.extend, auth state, data fixtures; api/ — API clients (for data prep + API tests); test-data/ — factory functions (better than static JSONs — uniqueness and type safety); utils/ — helpers; config + CI files at root. Principles: no locators in specs, data comes from factories, each layer looks only downward (tests → pages/api → utils).

Question 2

Do you know POM alternatives? When can you skip POM?

Accepted Answer

Alternatives: (1) plain helper functions — enough for small suites; (2) the Screenplay pattern — actor/task/question abstraction, suits large teams but has a learning cost; (3) component objects — at the UI-component level rather than pages (natural for design-system apps). Skipping POM: full POM is overkill for a 10-15-test project — Playwright's user-facing locators are readable on their own. Rule: add abstraction when the need appears, not "just in case" upfront.

Question 3

How do you manage test data — what is the factory pattern?

Accepted Answer

A factory is a data-building function with defaults that accepts overrides: createUser({ role: 'admin' }). Advantages over static JSONs: (1) uniqueness (timestamp/uuid) — no parallel collisions; (2) type safety (TS Partial<T>); (3) single place of change; (4) tests show only scenario-relevant fields — the rest is default. In real systems the factory pairs with the API: the object is built locally, created on the backend via API, and deleted in fixture teardown.

Page Object Model and framework architecture

📚 Sources and documentation