はじめに
UIテスト自動化の王道といえば Page Object Model (POM) です。しかし、プロジェクトが大規模化すると、以下のような課題に直面します。
- Pageオブジェクトの肥大化: 1つのクラスにメソッドが集中し、メンテナンスが困難になる。
- DRY原則の崩壊: 複数のページにまたがる共通操作の置き場所に困り、コードが重複する。
- ツールの密結合: SeleniumからPlaywrightへの移行など、エンジンの変更がコードの全面書き換えを意味する。
これらの課題を解決するのが、SOLID原則をテスト設計に持ち込んだ Screenplay Pattern です。
1. Screenplay Pattern とは何か？
Screenplay Pattern は、「誰が（Actor）」「何ができるか（Ability）」に基づき、「何を遂行するか（Task/Interaction）」を組み立てる設計パターンです。
2. 核心アーキテクチャ：5 つの要素
Screenplay Pattern は、映画の劇本（スクリプト）のように 5 つの要素で構成され、それぞれが厳密な役割を持っています。
- Actor（役者）: テストの主体。Abilities を保持し、Tasks/Interactions を実行し、Questions に答えます。
- Ability（能力）: Actorが持っている技術的な手段（ブラウザ操作、API実行など）。下位の操作を Invoke（呼び出し） します。
- Task（タスク）: ビジネスプロセスを表現する高レベルの抽象。複数の Interactions で構成（Made up of）されます。
- Interaction（相互作用）: 原子的な操作（例：クリック）。Abilities によって実行可能になり、直接システムと対話します。
- Question（問い）: システムの状態を取得する手段。Abilities を利用してシステムの状態を確認し、Actorに「答え」を提供します。
3. アーキテクチャと実行フロー
Screenplay Pattern の各コンポーネント間の関係性は、以下のフロー図で表されます。この設計により、ビジネスロジック（Task）と技術詳細（Ability）が完全に分離されます。
このフローの美しさは、Interaction や Question が Ability を介してシステムを操作・確認する点にあります。Actorは自身の「能力」を駆使して「問い」に答える（Answers）形式をとるため、ブラウザエンジンが Selenium であろうが Playwright であろうが、上層の Task は一切変更する必要がありません。
4. Pythonによる実装例（Selenium/Playwright共存）
Pythonの強力なライブラリ ScreenPy を使うと、このアーキテクチャを容易に実装できます。
Abilityの注入
Actorに対して、実行時にどちらのブラウザエンジン（Ability）を使うかを決定します。
# Seleniumを使用する「能力」をJamesに与える
james = Actor.named("James").who_can(BrowseTheWebWithSelenium.using(driver))
# Playwrightを使用する「能力」をPaulに与える
paul = Actor.named("Paul").who_can(BrowseTheWebWithPlaywright.using(page))
共通タスクの実行
Actorがどのエンジン（Ability）を持っていても、ビジネスロジック（Task）の呼び出し方は完全に共通化されます。
# Actorは自分の能力（Ability）を使ってタスクを遂行する
# ビジネスロジック（Task）はエンジンの詳細を知る必要がない
actor.attempts_to(
Login.as_admin(),
Search.for_item("Python Testing")
)
# システムの状態を確認する（ActorがQuestionに答える）
actor.should(See.the(Text.of(WELCOME_MESSAGE), ReadsExactly("Welcome!")))
5. Screenplay Pattern 導入のメリット
- 究極の再利用性: タスクは小さな独立したクラス（Interactionsの集合）であるため、レゴブロックのように組み合わせが可能です。
-
メンテナンス性: UIの変更があった際、修正箇所は特定の
TaskまたはInteractionに限定され、他のロジックに影響を与えません。 - 高い可読性: コード自体が「James attempts to Login as admin（ジェームズが管理者としてログインを試みる）」と自然言語で記述されるため、生きた仕様書として機能します。
まとめ
Screenplay Pattern は、単なるデザインパターンではなく、「テストをソフトウェアエンジニアリングとして構築する」ための指針です。「ActorがAbilityを使ってTaskを遂行し、Questionに答える」という厳密な構造 に従うことで、複雑なUIテストも劇的に管理しやすくなります。
特に、SeleniumからPlaywrightへの移行を検討しているチームや、長期的な保守が必要な大規模プロジェクトにとって、このパターンは救世主となるでしょう。
参考リンク: