Electron E2EテストにPlaywright + CDPを導入すべき3つの理由 ― 手動テスト地獄からの脱却

Electronを使ったデスクトップアプリ開発では、リリース前の動作確認が大きな負担になります。特に複数タブを持つアプリケーションや、データ表示が複雑なUIでは、機能追加のたびに全画面を手動で確認する作業が発生します。今回紹介するのは、そんな手動テスト地獄から抜け出すための、Playwright + CDP（Chrome DevTools Protocol）を活用したE2Eテスト導入の実践例です。

個人開発者がゲームデータ検索・参照用のElectronアプリにE2Eテストを導入しようとした経緯から、なぜPlaywright + CDPの組み合わせが注目されるのかを深堀りします。

1. 確認範囲の爆発的な増加

複数タブを持つアプリケーションでは、1つの機能変更が複数の画面に影響を与えます。タブA、タブB、タブC...と、それぞれの表示を目視で確認していくと、1回のリリース前チェックに30分以上かかることも珍しくありません。

2. リグレッションの見落とし

新機能の追加時、意図しない既存機能への影響（リグレッション）を完全に検知するのは困難です。人間の注意力には限界があり、特に疲労時には致命的なバグを見逃すリスクが高まります。

3. 開発速度の低下

手動テストへの心理的負担が、「小さな改善を頻繁にリリースする」という健全な開発サイクルを阻害します。テストが面倒だから、変更をまとめてリリースしよう...という判断が、結果的にバグの発見を遅らせます。

Playwrightとは

PlaywrightはMicrosoftが開発したブラウザ自動化ツールです。Chromium、Firefox、WebKitに対応し、特にE2Eテストの文脈で広く採用されています。Seleniumと比較すると、以下の点で優位性があります:

CDP（Chrome DevTools Protocol）の役割

CDPは、ChromeおよびChromiumベースのブラウザを制御するための低レベルプロトコルです。Electronは内部でChromiumを使用しているため、CDPを通じてアプリケーションを直接制御できます。

Playwright + CDPの組み合わせにより、以下が実現します:

// Electronプロセスに接続してテスト実行
const { _electron } = require('playwright');
const app = await _electron.launch({ args: ['./path-to-app'] });
const window = await app.firstWindow();

// 通常のPlaywright APIでテスト
await window.click('#search-button');
await expect(window.locator('.result-item')).toHaveCount(10);

このコードは、実際のElectronアプリを起動し、ユーザー操作をシミュレートして、結果を検証します。

従来のElectronテスト手法との比較

ElectronのE2Eテストには、いくつかの選択肢がありました:

**1. Spectron（非推奨）**

Spectronは長年Electron公式のテストフレームワークでしたが、2022年に非推奨となりました。WebDriverIOベースで動作が遅く、メンテナンスも停止しています。既存プロジェクトで使用している場合は、早急な移行が必要です。

**2. Puppeteer**

Googleが開発したブラウザ自動化ツールで、Chromiumに特化しています。Electronとも統合可能ですが、以下の点でPlaywrightに劣ります:

**3. Playwright + CDP（推奨）**

現時点で最も推奨される選択肢です。理由は:

メリットと注意点の両面分析

**メリット:**

1. **開発速度の向上**: 手動テストが30分→自動化で5分に短縮される例も

2. **リグレッション検知**: 既存機能の破壊を即座に検出

3. **リファクタリングの安心感**: テストがセーフティネットとなり、大胆なコード改善が可能

4. **ドキュメントとしての価値**: テストコードが仕様書の役割を果たす

**注意点:**

1. **初期セットアップのコスト**: 最初のテスト環境構築に時間がかかる（5〜10時間程度）

2. **メンテナンス負担**: UIが変わるたびにテストコードの修正が必要

3. **学習曲線**: Playwrightの概念（Locator、Page Object等）の理解が必要

4. **CI/CD統合の複雑さ**: 特にGUIアプリのヘッドレステストには工夫が必要

ただし、これらの注意点は「テストを書かない」理由にはなりません。初期投資は確かに必要ですが、中長期的には圧倒的にリターンが大きいです。

適用範囲の考察

**Playwright + CDPが特に効果的なケース:**

**優先度が低いケース:**

アクション1: 最も重要な1つのフローをテスト化する

いきなり全機能をテストしようとせず、「アプリ起動→検索→結果表示」といった最も重要な1つのユーザーフローから始めましょう。これだけで、大半のリグレッションを検知できます。

# プロジェクトにPlaywrightをインストール
npm install -D @playwright/test playwright

# Electronサポートを追加
npm install -D @playwright/test playwright-electron

アクション2: 「落ちやすい」部分を優先的にカバーする

過去にバグが頻発した機能、複雑なロジックを持つ部分を優先的にテスト化します。パレートの法則に従い、20%のコードが80%のバグを生み出しています。その20%をテストでカバーするだけで、大きな効果が得られます。

アクション3: CI/CDパイプラインに組み込む

ローカルでテストが動くようになったら、GitHub ActionsやCircleCIなどのCI/CDに統合しましょう。プルリクエストのたびに自動テストが走る環境を作れば、レビュー時の心理的負担が激減します。

# .github/workflows/test.yml の例
name: E2E Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
      - run: npm ci
      - run: xvfb-run npm test  # ヘッドレス環境でGUIアプリを実行

ElectronアプリのE2Eテスト導入は、短期的にはコストがかかります。しかし、手動テストを続けることは「技術的負債」を積み上げる行為です。Playwright + CDPの組み合わせは、現時点で最も効率的なElectronテストソリューションであり、投資する価値があります。

次回の記事では、実際のセットアップ手順と、筆者が遭遇した3つの落とし穴について詳しく解説される予定です。Electronアプリ開発者は必見の内容となるでしょう。

この情報は @yamada-ai-dev さんの投稿を参考にしています。