O que o Page Object deveria resolver
Uma página costuma concentrar detalhes de interface: locators, preenchimento de componentes, abertura de modais e ações que aparecem em vários cenários. Quando esses detalhes ficam espalhados pelos specs, qualquer mudança de interface exige alterações em vários lugares.
O Page Object cria uma fronteira: o teste expressa o fluxo e a página concentra a mecânica necessária para executá-lo.
await webTables.visit();
await webTables.addRecord(record);
await webTables.editDepartment(record.email, 'Quality Engineering');
await webTables.deleteRecord(record.email);Esse nível de leitura comunica o comportamento sem obrigar o spec a conhecer cada seletor da tabela.
Abstração não deve esconder intenção
O problema começa quando cada clique ganha um método, cada locator vira uma propriedade pública e novas classes são criadas apenas para obedecer a um padrão arquitetural. O resultado pode exigir navegar por vários arquivos para entender um teste de poucas etapas.
Uma abstração tem valor quando reduz conhecimento duplicado ou concentra uma regra de interação. Se ela apenas muda o lugar onde uma linha de código está escrita, o benefício precisa ser questionado.
Comportamento em vez de detalhes
Prefira métodos que representem ações relevantes da página. Em uma Web Table, addRecord() é uma unidade coerente: abrir o formulário, preencher campos, enviar e confirmar que o registro apareceu.
Isso é diferente de expor uma sequência como clickAdd(), fillFirstName(), fillLastName() e clickSubmit() apenas para o spec reconstruir a implementação da página.
Assertions: onde colocar?
Não existe uma regra absoluta de que toda assertion deve estar no spec ou no Page Object. A decisão depende do significado da validação.
Uma verificação estrutural necessária para garantir que uma ação terminou corretamente pode ficar próxima da ação. Já uma expectativa que representa o objetivo específico do cenário deve permanecer visível no teste quando isso melhora sua intenção.
O critério é evitar dois extremos: Page Objects que não garantem nada sobre suas próprias ações e Page Objects que escondem todas as expectativas a ponto de o spec deixar de comunicar o que está sendo validado.
Um exemplo do laboratório
No cenário de Web Tables, a linha é localizada pelo e-mail criado durante o teste, e não por sua posição visual. Esse conhecimento pertence à interação com a tabela e pode ser encapsulado:
private getRowByEmail(email: string) {
return this.page.locator('table tbody tr', { hasText: email });
}Se a posição do registro mudar, o cenário continua trabalhando com a identidade do dado. O spec não precisa duplicar a estratégia de localização.
Quando não criar um Page Object
- quando o cenário é pequeno e não há comportamento reutilizável;
- quando a abstração só renomeia métodos nativos do Playwright;
- quando ainda não existe repetição suficiente para entender qual abstração é estável;
- quando a camada torna o fluxo mais difícil de ler do que o código direto.
O critério mais útil
Page Object Model não deveria ser uma meta de cobertura arquitetural. Ele é uma ferramenta para controlar mudança. Crie a abstração quando ela concentra conhecimento que provavelmente mudará junto e quando deixa o teste mais claro.
Em automação, menos código não é necessariamente melhor, mas mais camadas também não significam mais engenharia. A estrutura deve pagar pelo custo cognitivo que adiciona.