Page Object Model (POM)

O Page Object Model (POM) reúne em uma única classe tudo o que um teste precisa saber sobre uma página: seus locators e as ações que o usuário pode executar nela. Assim, os testes ficam parecidos com a jornada do usuário (loginPage.signIn(user)) e, quando o markup muda, você corrige uma classe em vez de todos os testes.

Um exemplo mínimo (Playwright, TypeScript)

import { type Page, type Locator } from '@playwright/test';

export class LoginPage {
  readonly email: Locator;
  readonly password: Locator;
  readonly submit: Locator;

  constructor(private readonly page: Page) {
    this.email = page.getByLabel('Email');
    this.password = page.getByLabel('Password');
    this.submit = page.getByRole('button', { name: 'Sign in' });
  }

  async goto() {
    await this.page.goto('/login');
  }

  async signIn(email: string, password: string) {
    await this.email.fill(email);
    await this.password.fill(password);
    await this.submit.click();
  }
}

Regras que mantêm os page objects úteis

• Nada de assertions dentro dos page objects, exceto verificações de que a própria página carregou. Quem decide o que é “correto” é o teste.
• Retorne o próximo page object nas ações que navegam, ou não retorne nada. Evite retornar handles de elementos crus.
• Modele componentes, não só páginas. Um header, uma tabela de dados ou um date picker que aparece em muitas páginas merece uma classe própria.
• Mantenha-os enxutos. Regras de negócio, massa de dados e chamadas de API pertencem a outras camadas, como fixtures e clientes de API.

Críticas comuns

Page objects grandes viram “god classes” com dezenas de métodos. Dividir por componente e usar fixtures para criar os page objects de cada teste os mantém pequenos. Alguns times preferem o padrão Screenplay para suítes muito grandes, mas o POM continua sendo a estrutura mais comum em frameworks de Selenium e Playwright, e é a que os entrevistadores esperam que você saiba explicar.