메뉴
Compact reference for organising Playwright tests with page objects. Use when adding a new page or refactoring a spec that has grown messy. Not a style lecture — see sibling skills for locators, fixtures, debugging, etc.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Decide WHEN to drive the browser MCP, WHEN to invoke a Playwright Test Agent (planner/generator/healer), and WHEN to just edit files. The orchestrator skill — read this first when a Playwright task comes in.
Mix API calls into Playwright suites — pure API tests via the request fixture and hybrid tests that seed state via API then assert through the UI. Use when login/setup is slow, when verifying side-effects, or for API regression coverage alongside UI.
Use Playwright as an investigation tool, not just a regression suite — broken-image audits, console-error capture, failed-request capture, negative-path tests, accessibility scans. Use during exploratory testing or whenever a real bug is suspected but not reliably reproducible.
Unblock a failing or hard-to-author Playwright test — UI mode, codegen, trace viewer, Inspector, page.pause(), failure artifacts. Use whenever a test fails mysteriously, when you need to discover a locator, or when stepping through a flow.
Build custom Playwright fixtures, skip repeated login with storage state, and keep tests isolated so they run in any order in parallel. Use when tests need auth, share setup, or are slow because every test re-logs-in.
Pick locators that survive UI changes and lean on Playwright's auto-waiting to kill flakes. Use when authoring or refactoring a spec, replacing brittle CSS/XPath, or chasing flaky failures.
| name | playwright-page-object |
| description | Compact reference for organising Playwright tests with page objects. Use when adding a new page or refactoring a spec that has grown messy. Not a style lecture — see sibling skills for locators, fixtures, debugging, etc. |
Page objects are one tool for keeping specs readable. Reach for them when a page is used by ≥2 tests or a spec is getting noisy. Don't introduce them just to follow a pattern.
Working examples already in this repo:
pages/login.page.tspages/inventory.page.tstests/fixtures.ts (how the page objects get into tests)<thing>.page.ts, class <Thing>Page.private readonly, set in the constructor. Don't expose selectors to tests.login(user, pass)), not mechanics (clickAndType).expect() inside the page object — assertions live in the spec so the test reads like a spec. Expose locators/getters for the test to assert on.goto().That's it. If a page object grows past ~80 lines, split it.
See examples/todo.page.ts for a minimal shape, and pages/login.page.ts in this repo for a real one used by the fixture in tests/fixtures.ts.
Workshop exercises in .roo/WORKSHOP_GUIDE.md.