Q: Fixtures vs beforeEach — which do you choose when?

My rule is simple: if you create something that must be cleaned up — a fixture; if you just navigate to the same page — a hook. Three concrete advantages of fixtures: (1) lazy instantiation — if it isn't in the test's arguments it never runs at all, whereas beforeEach applies to every test in the block including those that don't need it (creating a user for 2 of 10 tests means 8 wasted users); (2) typing — the created object arrives as a test argument, while beforeEach needs a shared variable, which is itself a trap under parallel execution; (3) composition — an order fixture can depend on a user fixture and Playwright resolves the order itself. But I'm not dogmatic: writing a fixture for beforeEach(() => page.goto('/')) is needless complexity. That part of the answer matters — in interviews "always X" answers read as weak, while context-driven choices read as strong.

Question 1

How would you organise a 500-test suite?

Accepted Answer

I speak in four dimensions, because the question is about structure, execution and process at once. File structure: folders by feature (tests/checkout/, tests/auth/), file names matching the feature, logical groups via describe blocks. A tag system: @smoke (critical minimum, on PRs, <10 min), @regression (full coverage, nightly), @slow, @flaky (quarantine, run separately and blocking nobody). Tags are documented as a convention, otherwise everyone invents their own. Execution strategy: smoke on PRs; an extended set after merge; full regression nightly with sharding (4-8 machines). This is only possible because tests are fully independent — serial mode strictly where unavoidable. Ownership and hygiene: every feature folder has an owner; skip/fixme always carries a ticket link; a quarterly "dead test" cleanup — tests that never fail and never catch anything are the candidates. The closing emphasis: the main problem with 500 tests isn't technical, it's trust. If the suite is slow and flaky, people stop looking at it — which is why duration and flaky rate are my first-order metrics.

Question 2

Fixtures vs beforeEach — which do you choose when?

Accepted Answer

My rule is simple: if you create something that must be cleaned up — a fixture; if you just navigate to the same page — a hook. Three concrete advantages of fixtures: (1) lazy instantiation — if it isn't in the test's arguments it never runs at all, whereas beforeEach applies to every test in the block including those that don't need it (creating a user for 2 of 10 tests means 8 wasted users); (2) typing — the created object arrives as a test argument, while beforeEach needs a shared variable, which is itself a trap under parallel execution; (3) composition — an order fixture can depend on a user fixture and Playwright resolves the order itself. But I'm not dogmatic: writing a fixture for beforeEach(() => page.goto('/')) is needless complexity. That part of the answer matters — in interviews "always X" answers read as weak, while context-driven choices read as strong.

Question 3

How do you establish a tag convention and keep it from eroding?

Accepted Answer

First I keep the number of tags small — a system with more than five becomes unusable within a year because nobody knows which to pick. My set: @smoke, @regression, @slow, @flaky, @wip. Each tag gets a one-sentence definition and selection criterion: for example, "@smoke — if it fails, the release must be blocked". Without a definition tags become subjective and everyone considers their own test a smoke test (the classic outcome: a 200-test "smoke" suite). Enforcement comes from automation, not reminders: (1) a small CI check that no test is left untagged; (2) a time budget for the @smoke set — when it exceeds 10 minutes the pipeline warns and the team either optimises or moves tests to regression; (3) one line in the PR checklist. I'd add that a convention can't be set once and forgotten — I review the smoke set quarterly: after real incidents some tests deserve promotion into smoke, while others no longer earn their place and come out.

Annotation	Meaning	When to use
test.skip(reason)	The test is not run	A precondition isn't met (e.g. the feature is absent in this environment) — a reason is required
test.fixme(reason)	The test is broken and a fix is pending	Quarantine — together with a ticket link
test.fail()	Failure is EXPECTED; passing raises an alarm	A known unfixed product bug — you learn the moment it's fixed
test.slow()	Timeout tripled	A genuinely long flow (report generation, a batch job)
test.only()	Only this test runs	Local debugging; must be lint-blocked from reaching main

Test organisation: tags, hooks, steps, annotations

📚 Sources and documentation