Seleniumの亡霊を葬れ:Playwrightで実現する「壊れない」E2Eテストの正攻法

Seleniumの亡霊を葬れ:Playwrightで実現する「壊れない」E2Eテストの正攻法

深夜2時、コンパイルエラーの赤文字よりも、CIのテスト結果が「緑」から「赤」に変わる瞬間の方が心臓に悪い。SeleniumでWebDriverのバージョン不整合と戦い、Cypressのクロスドメインの壁に頭を抱えていたあの頃の自分を殴りに行きたい。

E2Eテストは「書くのが面倒」なのではない。「壊れやすく、デバッグが困難だから」避けるのだ。しかし、Playwrightという選択肢を得た今、その常識は過去のものになった。本稿では、単なる導入手順ではなく、実戦で「生き残る」テストパイプラインの構築論を記す。


1. なぜPlaywrightは「速い」のか:技術的アーキテクチャの真実

SeleniumがWebDriverプロトコル(HTTPベースのシリアライズされた通信)を介してブラウザを操作するのに対し、PlaywrightはCDP(Chrome DevTools Protocol)をWebSocket経由で直接叩く。

この差は決定的だ。Seleniumはコマンドの送受信にオーバーヘッドが発生し、ブラウザとの同期に「明示的な待機」を強いるが、Playwrightはブラウザの内部状態をイベント駆動で監視する。

特徴SeleniumCypressPlaywright
通信プロトコルWebDriver (HTTP)ブラウザ内実行CDP (WebSocket)
並列実行苦手(重い)苦手(プロセス依存)ネイティブ対応(超高速)
マルチブラウザ脆弱不可完璧(WebKit含む)

このアーキテクチャこそが、Playwrightが「爆速」である物理的根拠だ。


2. 現場で使える「堅牢な」テストコードの書き方

`waitForSelector`を連打する時代は終わった。PlaywrightのAuto-waitingは優秀だが、アニメーションを伴うUIに対しては、開発者の「DOM理解」が試される。

アンチパターンと正攻法

`{ force: true }` を使うのは、あくまで「どうしてもクリックできない」時の最終手段だ。これを乱用すると、ユーザーが実際に操作できない要素をテストが通過させてしまう(偽陽性の温床)。

// 【推奨】可視性確認を待機チェーンに含める
const submitBtn = page.locator('#submit-btn');

// アニメーション完了まで待機し、インタラクティブになった瞬間に操作する
await expect(submitBtn).toBeVisible();
await submitBtn.click();

// 【非推奨】力技でのクリック(テストが壊れやすくなる)
// await page.locator('#submit-btn').click({ force: true });

また、認証情報は必ず環境変数で管理すること。`.env`をGit管理下に置くなどというミスは、AWSキーを漏洩させた瞬間にキャリアを焼く。


3. CI/CDパイプライン最適化:失敗を「資産」に変える

ローカルで通るテストに価値はない。CIで落ちてこそ、初めてプロダクトの安全性が証明される。GitHub Actionsでの構成は、単に「テストを走らせる」だけでなく「失敗の理由を即座に特定する」ためのメタデータを残す必要がある。

# .github/workflows/playwright.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm ci
      - name: Run Playwright
        run: npx playwright test
      - name: Upload Artifacts
        if: always() # 失敗してもレポートを残す
        uses: actions/upload-artifact@v3
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 7

プロのCI戦略

  • Artifactsの保存: テスト失敗時に生成される「トレースファイル(`.zip`)」を必ず保存しろ。これがあれば、ローカルで再現できない謎の落ち方も、UIのスクリーンショットやネットワークログを辿って原因を特定できる。
  • 動画撮影: `playwright.config.js` で `video: 'retain-on-failure'` を設定せよ。失敗した瞬間のブラウザの挙動が見えるだけで、デバッグ時間は半分になる。

4. 最後に:自動化は「コスト」ではなく「保険」である

E2Eテストは、書くコストを惜しんで機能をリリースし、翌朝の障害対応で徹夜するリスクと比較すれば、圧倒的に安い投資だ。

Playwrightは単なるツールではない。「深夜のデプロイを安心して行うための精神安定剤」だ。

もし今、Seleniumのコードを眺めて溜息をついているなら、今すぐ乗り換えろ。フロントエンドの変更に追従できなくなったテストコードを保守し続ける時間は、エンジニアが最も無駄にしているリソースだ。

さあ、コーヒーを淹れ直して、緑のバーで埋め尽くされたテストレポートを眺める準備をしよう。自動化をサボるな。コードは裏切るが、テストは嘘をつかない。