페이지 객체 모델(POM)

페이지 객체 모델(Page Object Model, POM)은 테스트가 한 페이지에 대해 알아야 하는 모든 것, 즉 그 페이지의 로케이터와 사용자가 그곳에서 할 수 있는 동작을 하나의 클래스에 담습니다. 그러면 테스트가 사용자 여정처럼 읽히고(loginPage.signIn(user)), 마크업이 바뀌었을 때 모든 테스트를 고치는 대신 클래스 하나만 고치면 됩니다.

최소 예시 (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 프레임워크에서 가장 흔한 구조이며 면접관이 설명해 보라고 기대하는 패턴입니다.