ページオブジェクトモデル（Page Object Model）

ページオブジェクトモデル（POM）は、あるページについてテストが知っておくべきこと、つまりロケーターとそのページでユーザーが行える操作を、1 つのクラスにまとめるパターンです。テストはユーザーの操作の流れのように読めるようになり（loginPage.signIn(user)）、マークアップが変わったときも、すべてのテストではなく 1 つのクラスを直すだけで済みます。

最小限の例（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();
  }
}

ページオブジェクトを有用に保つルール

• ページオブジェクトの中にアサーションを書かない。 例外はページ自体が読み込まれたことの確認だけです。何が「正しい」かを決めるのはテストの役割です。
• 画面遷移する操作からは次のページオブジェクトを返すか、何も返さないようにします。生の要素ハンドルを返すのは避けましょう。
• ページだけでなくコンポーネントもモデル化する。 多くのページに登場するヘッダー、データテーブル、日付ピッカーなどは、それぞれ専用のクラスにする価値があります。
• 薄く保つ。 ビジネスルール、テストデータ、API 呼び出しは、フィクスチャや API クライアントなど別のレイヤーに置きます。

よくある批判

大きなページオブジェクトは、何十ものメソッドを持つ「神クラス（god class）」になりがちです。コンポーネント単位で分割し、テストごとにフィクスチャでページオブジェクトを生成すれば、小さく保てます。非常に大規模なスイートでは Screenplay パターンを好むチームもありますが、POM は今も Selenium や Playwright のフレームワークで最も一般的な構造であり、面接で説明を求められるのもこのパターンです。