Electron アプリのエンドツーエンドテスト: Playwright の Electron サポートの先へ

このガイドは、Electron デスクトップアプリの開発者と QA 担当者のためのものです。そうしたアプリのテストは何が違うのかを述べ、Playwright の Electron API を公平に紹介したうえで、ページ、ネイティブのファイルダイアログ、エクスポートとその通知を通る 1 件のエンドツーエンドテストを示し、それをすべてのビルドで実行します。

Electron アプリのテストは何が違うのか

Electron アプリは、協力して動く 2 つのプログラムです。メインプロセスは Node.js で動きます: ウィンドウを開き、アプリのライフサイクルを受け持ち、メニュー、ダイアログ、トレイアイコンなどネイティブなものすべてをオペレーティングシステムに依頼します。そして各ウィンドウはレンダラープロセスを動かし、それは Chromium のページです: Web サイトと同じ HTML、CSS、JavaScript です。

テストにとって、この分かれ方は重要です。Web サイト向けに作られたツールは、ページだけを見ます。ユーザーは全体を見ます: メニューバー、「開く」で開く Windows のファイルダイアログ、エクスポートの完了を告げるトースト、ウィンドウを閉じたあともトレイに残るアイコンです。

Playwright の Electron API がカバーする範囲と、止まる場所

Electron の UI テストツールの中で、ほとんどのチームが最初に試すのは、Web アプリですでに使っている Playwright です。その Electron クラスは、Electron 21 以降向けの実験的なサポートとしてドキュメント化されています。テストはエントリスクリプトからアプリを起動し、各ウィンドウを Playwright のページとして取得し、evaluate() でメインプロセスの中でコードを実行します。

これはアプリの内部に本当に届く手段です。Playwright が Web ページで提供するあらゆるロケーター、クリック、アサーションがレンダラーで使え、2 つ目のウィンドウは window イベントを通じて届き、evaluate() はアプリの状態を読んだり変えたりできます。完全な一覧は ElectronApplication クラスを参照してください。

止まる場所も同じくらい明確にドキュメント化されています。dialog.showOpenDialog のようなネイティブダイアログの呼び出しはオペレーティングシステムに直接渡るため捕捉されず、ドキュメントは、テストからそれらのメソッドを望むファイルパスを返すスタブに置き換えるよう勧めています。実際のダイアログは決して開かないので、決してテストされません。ページの外でオペレーティングシステムが描画するその他すべてについても同じことが言えます。

事実は 2026 年 11 月 6 日に Playwright のドキュメントで確認したものです。Playwright と Electron はそれぞれの所有者の商標であり、このガイドはそれらと提携しておらず、承認も受けていません。

レンダラーとシェルをまたぐ 1 件のエンドツーエンドテスト

請求書アプリを例に、GUI Test Studio で Electron アプリをエンドツーエンドでテストする方法を示します: ネイティブダイアログでファイルを開き、1 行を編集し、PDF をエクスポートし、完了を告げる通知を検証します。

1. 1

   ページではなく、アプリを記録する

   GUI Test Runner-Recorder で記録をクリックし、アプリを選びます。Electron アプリを選ぶか、その実行ファイルを参照し、テストと一緒にアプリを起動して最後に終了するチェックボックスをオンにすると、すべての実行がまっさらなアプリから始まります。あとはユーザーと同じように使ってください。

   

   拡大

2. 2

   実際のダイアログでファイルを開く

   「開く」をクリックします。記録にとって、Windows のファイルダイアログは他と変わらない 1 つのウィンドウです: ファイル名の欄にファイルのパスを入力して Enter を押すと、どちらも実際の入力として記録されます。クリックの前にダイアログのアサーションが記録されるので、実行はダイアログが本当に表示されるまで待ちます。

   多くの Electron アプリは Web ページとしても提供されています。同じ画面のそのバージョンでは、ファイルをアップロードのステップがダイアログなしでファイルをページに渡します。

3. 3

   編集し、エクスポートし、トーストを読む

   数量を変え、「エクスポート」をクリックします。通知が現れたら、停止する前に少しそのままにしておきます: 記録が表示されたものを書き留め、テストはそのアサーションを得ます。

4. 4

   テストが何を検証すべきかを指定する

   停止すると、GUI Test Runner-Recorder はテストで何を検証するかを尋ねます: クリックした要素、テキスト、画面に表示されたものです。3 つともオンのままにしておきます。すると各ステップは GUI Test Studio のタイムライン上のブロックになり、その中にプロセスの名前は一切出てきません。

重要なアサーション: テキスト、ビジュアル、レイアウト

記録は、クリックの狙いを定めるアサーションをテストに与えます。手で追加する価値があるのは、Electron アプリが最もよく壊す部分を捉えるアサーションです。

すべての比較は、2 回の実行に必ずある描画のノイズ、ここが少し明るい、あそこの縁が少し柔らかいといったものを無視し、それでも人が変化と呼ぶ本当のリグレッションを捉えます: 欠けたアイコン、変わった言葉、色の違うボタンです。各アサーションの厳しさはビジュアルアサーションを参照してください。

すると信頼度レポートが、アサーションごとに、要素が見つかったか、記録どおりに見えるかを、期待画像と実際に見つかった画像を並べて示します。Windows がコントロールを説明できないデスクトップアプリでも、同じ手法が見た目だけで機能します: アクセシビリティツリーのない Windows アプリのテストを参照してください。

すべてのビルドでの Electron の自動テスト

コマンドラインの実行ツールである gtr-cli は、「テストを実行」ボタンとまったく同じようにテストを実行し、パイプラインに必要なものを加えます: 終了コード、JUnit ファイル、そして 1 つのフォルダーにまとめた失敗のすべてのエビデンスです。

gtr-cli run tests\electron --countdown 0 --junit results\junit.xml --artifacts results\artifacts

テストの冒頭の「アプリを実行」ステップが、テスト対象のビルドを起動します: ビルドが作ったパッケージ済みの実行ファイルを指定すれば、同じテストが出荷するすべてのバージョンを検証します。アプリは実際の画面に描画するので、ビルドエージェントにはサインイン済みでロックされていない Windows のデスクトップセッションが必要です。CI/CD ガイドが TeamCity、Jenkins、GitHub Actions、GitLab、Azure DevOps 向けの設定を説明しています。

拡大

ここでは当てはまらないことが 1 つあります。GUI Test Studio の「ブラウザーとデバイス」は、クロスブラウザーテストで説明しているとおり、Web テストの Chrome、Edge、Firefox、エミュレートしたスマートフォン向けのバージョンを作ります。Electron アプリは独自の Chromium を同梱しているので、テストするブラウザーは 1 つで、重要なバージョンとはビルドのことです。

Playwright の Electron API が今も正しい選択であるとき

公平なガイドは相手のツールが勝つ場所も述べるもので、ここがそれです。Playwright の Electron API はメインプロセスのコードレベルのテストに正しい選択です: evaluate() はアプリの状態を直接読み、スタブ化したダイアログはファイル処理のテストを速く正確にし、どれにも画面は必要ありません。Web アプリ向けにすでに Playwright のテストを書いているチームは、レンダラーでロケーターと習慣をそのまま使い続け、それらのテストをプルリクエストのたびに数秒で実行します。

2 つはライバルではありません。レンダラーとメインプロセスには Playwright を、ユーザーがシェルをたどる一連の流れには画面のテストを使います: 実際のビルドでの、実際のダイアログ、実際のメニュー、実際の通知です。それぞれが、相手には見えないものを捉えます。

要点

• 1Electron アプリはページとシェルの組み合わせです: メインプロセスがダイアログ、メニュー、トレイ、通知を受け持ち、ユーザーはそのすべてに出会います。
• 2Playwright の Electron API はコードからページとメインプロセスに届きますが、そのドキュメント自身が、ネイティブダイアログは捕捉されないと述べています。
• 3GUI Test Studio はユーザーが見るとおりにアプリをテストします: 画面全体を記録し、実際のファイルダイアログを他のウィンドウと同じように操作し、テスト用ビルドもプラグインもありません。
• 4テキスト、ビジュアル、レイアウトのアサーションが壊れた箇所を捉えます: 間違った合計、欠けたアイコン、グレーアウトしたメニュー項目、別のウィンドウの後ろのウィンドウです。
• 5同じテストが gtr-cli でビルドのたびに実行され、パイプライン用の JUnit ファイルを書き出します。「ブラウザーとデバイス」は Web ページ向けで、ここでのバージョンとはビルドのことです。

よくある質問

Electron、Playwright、Chromium、Node.js、Windows、TeamCity、Jenkins、GitHub、GitLab、Azure DevOps はそれぞれの所有者の商標です。