Page Object Model with Intent-Based Actions#

One thing I’ve realized is key to maintainable page objects is focusing on business actions rather than UI implementations. Public methods should describe what the user wants to achieve, not how the UI makes it happen.

So many times a function will be very specific to the implementation, and has to be changed in nearly every single spec file in order to be accurate to the actions being completed.

1
await page.clickNameField();
2
await page.typeFirstName('John');
3
await page.clickNextButton();
4
await page.selectFromDropdown('Owner');

1
await page.addOwnerDetails({
2
  firstName: 'John',
3
  role: 'Owner'
4
});

1
// Page object extends the base class
2
export class ApplicationPage extends PageComponent {
3
  // Private UI implementation details
4
  private readonly firstNameField: Locator;
5
  private readonly roleDropdown: Locator;
6
  private readonly submitButton: Locator;
7

8
  constructor(page: Page) {
9
    super(page);
10
    this.firstNameField = page.getByRole('textbox', { name: 'First Name' });
11
    this.roleDropdown = page.getByRole('combobox', { name: 'Role' });
12
    this.submitButton = page.getByRole('button', { name: 'Submit' });
13
  }
14

15
  // Private locator helpers
16
  private getRoleOption(role: string): Locator {
17
    return this.page.getByRole('option', { name: role });
18
  }
19

20
  // Private field setters
21
  private setFirstName = this.withOptionalValue(async (value: string) => {
22
    await this.firstNameField.fill(value);
23
  });
24

25
  private selectRole = this.withOptionalValue(async (role: string) => {
26
    await this.roleDropdown.click();
27
    await this.getRoleOption(role).click();
28
  });
29

30
  // Public methods express business intent
31
  async addOwnerInformation(info: {
32
    firstName?: string;
33
    role?: string;
34
  }) {
35
    await this.setFirstName(info.firstName);
36
    await this.selectRole(info.role);
37
  }
38

39
  // High-level business action
40
  async submitApplication(): Promise<void> {
41
    await this.submitButton.click();
42
  }
43
}

High-level fill methods accept partial data#

Accepting partial payloads lets tests pass only the fields relevant to a scenario and reduces churn when forms evolve.

1
async fillOwnerInformation(payload: {
2
  firstName?: string;
3
  lastName?: string;
4
  representative?: { type?: string; id?: string };
5
}) {
6
  await this.setFirstName(payload.firstName);
7
  await this.setLastName(payload.lastName);
8
  // more setters...
9
}

TIP

Keep all selectors within page objects, treating them as the single source of truth for UI interactions. When elements move or change, updates only need to happen in one place

Centralized Data Factories and Fixtures#

Another crucial pattern is centralizing test data generation in factories and fixtures. This ensures that when data requirements change (e.g., new validation rules), you only need to update one place instead of hundreds of tests.

A nightmare I ran into was someone storing all their auth data (email, id, username, password) at the start of every test. Inevitably when the password requirements changed and this password needed to be changed, we were stuck refactoring hundreds of spec files to refactor how we were pulling the auth data.

This isn’t too terrible because it’s a few static strings, but I can imagine there’s going to be scenarios where this waste days of effort to refactor. Especially validation logic changes that make you go back and analyze your test data across all the tests

1
export function generateOwnerInformation() {
2
  return {
3
    firstName: validFirstName(),
4
    lastName: validLastName(),
5
    ssn: validSSN(),
6
    address: generateAddress(),
7
    contact: generateContactInfo()
8
  };
9
}
10

11
// Can compose smaller, focused factories
12
export function generateAddress() {
13
  return {
14
    street: '123 Main St',
15
    city: 'Springfield',
16
    state: 'IL',
17
    zip: '62701'
18
  };
19
}
20

21
// fixtures/test-data.ts
22
import { test as base } from '@playwright/test';
23
import { generateOwnerInformation } from './data-factories';
24

25
// Type for all our data factories
26
interface DataFactories {
27
  owner: ReturnType<typeof generateOwnerInformation>;
28
}
29

30
// Extend the test fixture with our data
31
export const test = base.extend<DataFactories>({
32
  owner: async ({}, use) => {
33
    await use(generateOwnerInformation());
34
  }
35
});

Then your tests stay clean and use the fixture data:

1
test('can submit owner application', async ({ page, owner }) => {
2
  const appPage = new ExampleApplicationStepPage(page);
3
  await appPage.fillOwnerInformation(owner);
4
  // ... rest of test
5
});
6

7
// Need different data? Override just what you need
8
test('handles missing contact info', async ({ page, owner }) => {
9
  const appPage = new ExampleApplicationStepPage(page);
10
  await appPage.fillOwnerInformation({
11
    ...owner,
12
    contact: undefined
13
  });
14
});

Data factories provide a single source of truth for test data, letting you build complex objects from smaller factories while maintaining type safety. This keeps tests focused on behavior and avoids using literals you’ll need to change across multiple tests.

Closing#

Automating repetitive, long E2E flows isn’t usually a good idea. But with careful design, strong OOP practices, and defensive helpers, it’s possible to make these flows not an absolute nightmare to maintain.