Use this skill when the main decision is architectural rather than tactical.
Decision Model
- Use fixtures for setup, teardown, shared state, and authenticated contexts.
- Use page objects to encapsulate repeated or complex UI behavior.
- Use helpers only for stateless utilities such as data generation, formatting, or pure transformations.
- Do not force page objects for every one-off interaction.
Practical Rules
- Reach for a page object when the same UI behavior appears in multiple tests or when the page flow is complex enough to deserve a named abstraction.
- Keep assertions close to the test unless a reusable page-level assertion adds clarity.
- Avoid helpers that accept a
Pageor mutate browser state. - Keep the testing support code organized with the tests it serves.
Read by Need
| Need | Guide |
|---|---|
| Page object design | page-object-model.md |
| POM vs fixture vs helper tradeoffs | pom-vs-fixtures-vs-helpers.md |
| Broader architecture decisions | ../core/test-architecture.md |