Build a Playwright Page Object Model Architecture

Generate a full POM structure with a base page class, individual page classes, typed Playwright fixtures, and an example test — all in TypeScript.

Who this is for

QA engineers learning or implementing the Page Object Model (POM) pattern in Playwright TypeScript. Suitable for teams migrating from procedural test scripts to a maintainable, scalable architecture.

Prompt Template

You are a senior SDET specialising in Playwright test architecture.

Generate a complete Page Object Model (POM) structure for {{appName}}, a {{appType}} application.

Pages to model: {{pageList}}

Deliverables:
1. **BasePage** class with shared helpers:
   - waitForPageLoad() using networkidle
   - navigate(path: string)
   - screenshot(name: string) for debugging
2. **Individual page class for each page** in {{pageList}}:
   - All locators as readonly Locator properties using data-testid attributes
   - Action methods that compose locator + interaction (e.g. fillEmail(val), clickSubmit())
   - Assertion helpers on the class (e.g. expectSuccessBannerVisible(), expectValidationError(field))
3. **Playwright fixture** (fixtures.ts) that injects all pages into tests — no manual instantiation in tests
4. **Example test file** showing 3–4 tests using the fixture

Constraints:
- No test logic in POM classes — they describe pages and actions only
- All methods return Promises, all locators typed as Locator
- Page classes must NOT import from each other
- No hard-coded waits — use Playwright's built-in auto-waiting
- Include a barrel export (index.ts) for all pages

Structure:
```
tests/
  fixtures.ts        ← Playwright test extension with page objects
  pages/
    base.page.ts
    {{pageList}}.page.ts (one per page)
    index.ts
  specs/
    example.spec.ts
```

How to use this prompt

1Copy the prompt and describe the page or component you want to model (e.g. 'Login page with email, password, submit button, and error message area').
2Specify your Playwright version and any TypeScript conventions your team uses.
3The AI generates a complete Page Object class with typed locators, action methods, and assertion helpers.
4Add the class to your project's page-objects directory and import it in your test files.
5Use the generated class in a test file to verify the pattern works end-to-end.

Example output

For a checkout page, the prompt generates a `CheckoutPage` class with: typed Playwright `Locator` properties for every interactive element, `fillDeliveryAddress()`, `selectPaymentMethod()`, `placeOrder()` action methods, and `expectOrderConfirmation()` assertion helper — all with JSDoc comments.

Limitations

Generated locators use data-testid attributes by default — if your app doesn't have these, pass your app's locator strategy (aria-label, role, CSS) in the input for better results.
The POM structure suits UI-heavy applications — for API-heavy test suites, consider a service-object pattern instead.
Very complex pages with dynamic content (infinite scroll, complex modals) may need additional manual modelling beyond what the prompt generates.

Automation Code Decoder CI/CD Pipeline Architect

playwright professional

Frequently asked questions

Should I create one Page Object per page or per component?v

For most apps, one Page Object per full page (or per major workflow) is the right balance. For component libraries or shared UI components used across many pages, a component-level object can reduce duplication.

How do I handle pages that are dynamically loaded?v

Use Playwright's built-in `waitFor` options on your locators and add a `waitForLoad()` method to your Page Object that explicitly waits for the page's loading indicators to resolve before interactions.

Can this prompt generate TypeScript or JavaScript?v

By default, the prompt generates TypeScript with strict types. Specify 'JavaScript' in the framework placeholder if your project uses plain JS.