Page Object Model (POM)

Il Page Object Model (POM) raccoglie in un’unica classe tutto ciò che un test deve sapere su una pagina: i suoi locator e le azioni che un utente può compiere lì. I test si leggono allora come il percorso dell’utente (loginPage.signIn(user)) e, quando il markup cambia, correggi una sola classe invece di tutti i test.

Un esempio minimo (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();
  }
}

Regole che mantengono utili i page object

• Nessuna asserzione dentro i page object, tranne i controlli che verificano che la pagina stessa sia stata caricata. È il test a decidere cosa significa “corretto”.
• Restituisci il page object successivo dalle azioni che navigano, oppure non restituire nulla. Evita di restituire handle grezzi degli elementi.
• Modella i componenti, non solo le pagine. Un header, una tabella di dati o un date picker che compare in molte pagine merita una classe propria.
• Mantienili snelli. Regole di business, dati di test e chiamate API appartengono ad altri layer, come fixture e client API.

Critiche comuni

I page object grandi diventano “god class” con decine di metodi. Suddividerli per componente e usare le fixture per creare i page object per ogni test li mantiene piccoli. Alcuni team preferiscono lo Screenplay pattern per suite molto grandi, ma il POM resta la struttura più diffusa nei framework Selenium e Playwright, e quella che i selezionatori si aspettano che tu sappia spiegare a un colloquio.