Playwright의 Page Object Model 응용편｜pytest Fixtures 연동과 컴포넌트 설계로 유지보수성을 한 단계 더 높이기

Page Object Model(POM)의 기본은 이해했지만, 실제 프로젝트에서 운용하다 보면 「매번 Page Object를 인스턴스화하는 게 번거롭다」 「헤더나 모달 등 공통 UI 코드가 각 페이지마다 중복된다」 「로그인 처리가 느려서 테스트 전체 실행 시간이 늘어난다」와 같은 벽에 부딪히는 경우가 있습니다. 이 글에서는 pytest의 Fixtures·Component Object 패턴·storage_state를 조합해, 기본 POM을 한 단계 더 끌어올리는 응용 테크닉을 소개합니다.

POM의 「페이지마다 클래스를 만든다」는 기본 원칙만으로는 테스트가 늘어날수록 또 다른 과제가 나타납니다. Fixtures와의 연동 설계가 실무 운용 효율을 크게 좌우합니다.

기본 Page Object Model을 도입한 프로젝트가 성장하면 다음과 같은 과제가 나타나기 시작합니다.

• 모든 테스트에서 LoginPage(page)·DashboardPage(page) 같은 인스턴스화 코드가 반복된다
• 헤더·사이드바·알림 모달 등 여러 페이지에 공통되는 UI 조작 코드가 각 Page Object에 중복된다
• 「로그인 → 대시보드 확인」 같은 테스트가 늘어날 때마다 로그인 처리가 반복 실행되어 전체 실행 시간이 늘어난다
• 여러 페이지를 넘나드는 업무 플로우(구매 절차 등)의 테스트 코드가, 여러 Page Object를 호출하는 긴 나열이 된다

이 글에서는 이러한 과제를 해결하는 4가지 응용 테크닉을 순서대로 소개합니다.

이 글의 위치

이 글은 Page Object Model의 기본(클래스 설계·POM 유무 비교·디렉터리 구성)을 이해하고 있는 분을 위한 응용편입니다. POM의 기초부터 복습하고 싶다면, 먼저 기초 글을 읽는 것을 추천합니다.

① pytest Fixture로 Page Object를 자동 주입하는 방법

기본 POM에서는 각 테스트 안에서 LoginPage(page)처럼 Page Object를 수동으로 인스턴스화합니다. 테스트가 늘어나면 이 초기화 코드가 여러 곳에 흩어져, 테스트의 본질(무엇을 검증하고 싶은지)이 읽기 어려워집니다. pytest Fixture가 Page Object 생성을 대신하도록 하면, 테스트 코드는 Page Object를 받아서 사용하기만 하면 됩니다.

❌ Fixture화 전：매번 인스턴스화하는 코드

from pages.login_page import LoginPage
from pages.dashboard_page import DashboardPage

def test_login_success(page):
    # 테스트할 때마다 Page Object 인스턴스화가 필요
    login_page = LoginPage(page)
    login_page.navigate()
    login_page.login("user@example.com", "secret123")

    dashboard_page = DashboardPage(page)
    assert dashboard_page.is_visible()

def test_login_failure(page):
    # 같은 인스턴스화 코드가 또 등장한다
    login_page = LoginPage(page)
    login_page.navigate()
    login_page.login("wrong@example.com", "wrongpass")
    assert login_page.is_error_visible()

✅ Fixture화 후：conftest.py에 주입 처리를 모으기

# conftest.py
import pytest
from playwright.sync_api import Page
from pages.login_page import LoginPage
from pages.dashboard_page import DashboardPage

@pytest.fixture
def login_page(page: Page) -> LoginPage:
    """LoginPage를 생성하고 로그인 페이지로의 이동까지 마친 뒤 전달한다"""
    lp = LoginPage(page)
    lp.navigate()
    return lp

@pytest.fixture
def dashboard_page(page: Page) -> DashboardPage:
    return DashboardPage(page)

# test_login.py
def test_login_success(login_page, dashboard_page):
    # 인스턴스화·이동이 끝난 상태에서 시작할 수 있다
    login_page.login("user@example.com", "secret123")
    assert dashboard_page.is_visible()

def test_login_failure(login_page):
    login_page.login("wrong@example.com", "wrongpass")
    assert login_page.is_error_visible()

② Component Object 패턴으로 공통 UI 분리하기

헤더·사이드바·알림 모달 등 여러 페이지에 공통으로 등장하는 UI 요소를 Page Object마다 작성하면, 같은 로케이터나 조작 메서드가 여러 곳에 중복됩니다. 이런 공통 UI는 Component Object로 독립시켜 각 Page Object에서 합성(컴포지션)하는 설계로 만들면 중복을 방지할 수 있습니다.

Component Object 정의

# components/header_component.py
from playwright.sync_api import Page

class HeaderComponent:
    """여러 페이지에 공통으로 표시되는 헤더의 Component Object"""

    def __init__(self, page: Page):
        self.page = page
        self.logout_button      = page.get_by_role("button", name="로그아웃")
        self.notification_icon  = page.get_by_test_id("notification-icon")
        self.search_input       = page.get_by_placeholder("검색")

    def logout(self) -> None:
        self.logout_button.click()

    def open_notifications(self) -> None:
        self.notification_icon.click()

    def search(self, keyword: str) -> None:
        self.search_input.fill(keyword)
        self.search_input.press("Enter")

Page Object에서 Component를 합성하기

# pages/dashboard_page.py
from playwright.sync_api import Page
from components.header_component import HeaderComponent

class DashboardPage:
    """대시보드 페이지의 Page Object"""

    def __init__(self, page: Page):
        self.page = page
        self.header = HeaderComponent(page)  # ← Component를 합성한다
        self.summary_card = page.get_by_test_id("summary-card")

    def is_visible(self) -> bool:
        return self.summary_card.is_visible()

# 테스트 코드에서는 header를 통해 접근할 수 있다
def test_logout_from_dashboard(dashboard_page):
    dashboard_page.header.logout()
    # ... 로그아웃 후 확인 ...

③ storage_state로 인증 상태를 재사용해 고속화하기

로그인이 필요한 테스트가 많은 프로젝트에서는 모든 테스트에서 매번 로그인 처리를 실행하는 것이 실행 시간을 늘리는 큰 요인이 됩니다. Playwright의 storage_state를 사용하면, 한 번 로그인한 상태(쿠키·localStorage)를 저장해 이후 테스트에서는 로그인 처리를 건너뛰고 재사용할 수 있습니다.

세션 단위로 인증 상태를 한 번만 생성하기

# conftest.py
import pytest
from playwright.sync_api import Browser, Page

@pytest.fixture(scope="session")
def authenticated_state(browser: Browser, base_url: str) -> dict:
    """테스트 스위트 전체에서 1회만 로그인하고 인증 상태를 저장한다"""
    context = browser.new_context()
    page = context.new_page()
    page.goto(f"{base_url}/login")
    page.get_by_label("이메일").fill("test@example.com")
    page.get_by_label("비밀번호").fill("Password123")
    page.get_by_role("button", name="로그인").click()
    page.wait_for_url("**/dashboard")

    state = context.storage_state()
    context.close()
    return state

@pytest.fixture
def authenticated_page(browser: Browser, authenticated_state: dict) -> Page:
    """저장된 인증 상태로 새로운 페이지를 만든다（로그인 처리를 건너뜀）"""
    context = browser.new_context(storage_state=authenticated_state)
    page = context.new_page()
    yield page
    context.close()

# test_dashboard.py
from pages.dashboard_page import DashboardPage

def test_dashboard_shows_summary(authenticated_page):
    # 로그인 처리 없이 인증된 상태에서 테스트를 시작할 수 있다
    dashboard_page = DashboardPage(authenticated_page)
    authenticated_page.goto("/dashboard")
    assert dashboard_page.is_visible()

④ Component / Page / Flow 3계층으로 책임을 분리하기

「상품을 장바구니에 담고 구매를 완료한다」와 같이 여러 페이지를 넘나드는 업무 플로우를 테스트할 때, 테스트 코드 안에서 여러 Page Object를 직접 호출하면 테스트의 의도를 파악하기 어려워집니다. 이런 경우에는 업무 플로우 자체를 Flow Object로 캡슐화하는 설계가 효과적입니다.

Flow Object는 「업무 플로우의 재사용」이 목적이며, Page Object를 대체하는 것이 아닙니다. 내부적으로는 기존 Page Object를 조합해서 사용할 뿐이며, Page Object 자체의 역할(하나의 화면에 대한 요소와 조작)은 그대로 유지됩니다.

Flow Object 구현 예시

# flows/checkout_flow.py
from playwright.sync_api import Page
from pages.cart_page import CartPage
from pages.shipping_page import ShippingPage
from pages.payment_page import PaymentPage

class CheckoutFlow:
    """「구매 절차」라는 여러 페이지에 걸친 업무 플로우를 정리한다"""

    def __init__(self, page: Page):
        self.cart_page = CartPage(page)
        self.shipping_page = ShippingPage(page)
        self.payment_page = PaymentPage(page)

    def complete_purchase(self, address: dict, card: dict) -> None:
        """장바구니 확인부터 결제 완료까지를 하나의 메서드로 실행한다"""
        self.cart_page.proceed_to_checkout()
        self.shipping_page.fill_address(address)
        self.shipping_page.proceed()
        self.payment_page.fill_card(card)
        self.payment_page.submit()

# test_checkout.py
def test_purchase_completes_successfully(checkout_flow):
    # 여러 페이지의 조작이 한 줄로 표현되어 테스트의 의도가 명확해진다
    checkout_flow.complete_purchase(
        address={"postal_code": "150-0001", "city": "서울시"},
        card={"number": "4242424242424242", "cvc": "123"},
    )
    assert checkout_flow.payment_page.is_confirmation_visible()

응용편에서 자주 발생하는 실수

FAQ

📋 정리

기본 POM이 「페이지마다 클래스를 나누는」 설계라면, 이 글에서 소개한 Playwright × pytest fixture를 활용한 응용 테크닉은 「테스트 스위트 전체를 어떻게 구조화할 것인가」라는 한 단계 위의 설계입니다. 모든 것을 한 번에 도입할 필요는 없습니다. 먼저 Fixture화부터 시작해서, 프로젝트 규모에 맞춰 조금씩 도입해보세요.