【要約】E2Eテストを保守できる形にするPage Object Model [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
E2Eテストを自動化する際、操作手順をそのままコードに記述すると、UIの変更がテストの壊滅的な失敗を招く。開発者は、画面の構造が変わるたびに膨大なテストコードの修正を強いられる。具体的には、以下の問題に直面する。
- ・UIのHTML構造が変わるたびに、多数のテストコードを修正する必要が生じる。
- ・「確認したいシナリオ」と「画面の実装詳細（セレクタ等）」が混在し、可読性が低下する。
- ・テストの目的が不明瞭になり、メンテナンスコストが指数関数的に増大する。
// Approach
テストコードと画面操作のロジックを分離するPage Object Model（POM）を採用し、役割を明確に分ける。テストには「何を確認するか」を、Page Objectには「どう操作するか」を記述する。具体的な手法は以下の通りである。
- ・テスト側には、シナリオと期待結果（Assertion）のみを記述する。
- ・Page Object側には、ロケータと具体的な操作メソッドをカプセル化する。
- ・巨大なクラスを避けるため、独立した部品単位で「Component Object」として分割する。
- ・アサーションは原則としてテスト側に残し、Page Objectは検証に必要な要素の提供に留める。
// Result
POMの導入により、UI変更時の修正箇所を特定のクラスに集約できる構造を実現する。これにより、画面変更の影響範囲を限定し、テストの継続的な運用を可能にする。具体的な成果は以下の通りである。
- ・UIのセレクタ変更時、該当するPage Objectのみを修正すれば全テストに反映される。
- ・テストコードがビジネスロジックに近い記述となり、可読性と再利用性が向上する。
- ・重複が見えた段階で切り出す「漸進的な導入」により、過剰な設計コストを回避できる。
Senior Engineer Insight
> POMは保守性のための「境界線」を作る技術であり、テストの安定性を直接解決するものではない。待機処理の不備は別途設計が必要だ。また、過度な抽象化は開発速度を削ぐ。現場では、テストの重複や修正コストの増大を検知したタイミングで、段階的に導入する「Just-in-timeな抽象化」が最も効率的である。