Page Object Model

Das Page Object Model (POM) bündelt alles, was ein Test über eine Seite wissen muss, also ihre Locatoren und die Aktionen, die ein Nutzer dort ausführen kann, in einer einzigen Klasse. Tests lesen sich dann wie die User Journey (loginPage.signIn(user)), und wenn sich das Markup ändert, korrigieren Sie eine Klasse statt jedes einzelnen Tests.

Ein minimales Beispiel (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();
  }
}

Regeln, die Page Objects nützlich halten

• Keine Assertions in Page Objects, abgesehen von Prüfungen, ob die Seite selbst geladen wurde. Was „korrekt“ bedeutet, entscheidet der Test.
• Das nächste Page Object zurückgeben, wenn eine Aktion navigiert, oder gar nichts zurückgeben. Vermeiden Sie es, rohe Element-Handles zurückzugeben.
• Komponenten modellieren, nicht nur Seiten. Ein Header, eine Datentabelle oder ein Datepicker, der auf vielen Seiten vorkommt, verdient eine eigene Klasse.
• Schlank halten. Geschäftsregeln, Testdaten und API-Aufrufe gehören in andere Schichten, etwa in Fixtures und API-Clients.

Häufige Kritik

Große Page Objects werden zu „God Classes“ mit Dutzenden von Methoden. Eine Aufteilung nach Komponenten und das Erzeugen der Page Objects pro Test über Fixtures halten sie klein. Manche Teams bevorzugen für sehr große Suites das Screenplay-Pattern, doch POM bleibt die gängigste Struktur in Selenium- und Playwright-Frameworks und diejenige, die Interviewer von Ihnen erklärt haben möchten.