iimon TECH BLOG

iimonエンジニアが得られた経験や知識を共有して世の中をイイモンにしていくためのブログです

Chrome拡張機能のE2Eテスト自動化を検討してみた

1. はじめに

こんにちは！iimonでフロントエンドエンジニアをしている「奥島」です！
なんと、アドベントカレンダー6日目という大役を任されました！光栄です！
...と言いたいところですが、実は体調不良でカレンダー記入が遅れてしまい、6日目しか残っていなかっただけです。。

突然ですが、皆さんはテストの自動化、どこまで進んでいますか？

「手動テスト、毎回同じことやってるな...」
「リリース前のテスト、時間かかりすぎ...」

こんな悩み、ありませんか？
自分のチームでもまさにこの課題に直面していました。

ということで、今回は E2Eテストの自動化 について書いていきます！

ちなみに5日目担当の比嘉さんはTSKaigi Kaga 2025に登壇されました！
まだご覧になっていない方は5日目の記事もぜひチェックしてみてください！

2. なぜE2Eテストの自動化を検討しているのか

現状の課題

弊社の「速いもん」はChrome拡張機能として提供しており、複数の不動産サイトで動作します。
そのため、リリース前のテストでは各サイトで動作確認が必要です。

現状は手動でテストを行っていますが、こんな課題があります：

テストに時間がかかる

  • 1サイトあたり約5時間
  • 対応サイトが複数あるため、全体では相当な時間に
  • 毎回ログインが必要


人的ミスのリスク

  • 手動テストはどうしても確認漏れが発生しやすい
  • 確認漏れでリリース後にサイト修正が必要になることも


自動化で解決したいこと

  • 繰り返しの手動テストから解放されたい
  • リグレッションテストを自動で回したい
    • ※リグレッションテスト：新機能追加やバグ修正後に、既存機能が壊れていないか確認するテスト
  • リリース前の確認時間を短縮したい

3. E2Eテストツールの比較

E2Eテストのツールはいくつかありますが、主要なものを調べてみました。

Playwright

Microsoftが開発しているテストフレームワークです。

項目 内容
対応ブラウザ Chromium / Firefox / WebKit
言語 JavaScript / TypeScript / Python / C#
特徴 高速、自動待機、Chrome拡張機能対応

Chrome拡張機能のテストに対応しているのが大きなポイントです。
公式ドキュメントにも拡張機能を読み込む方法が記載されています。

Puppeteer

Googleが開発しているNode.jsライブラリです。

項目 内容
対応ブラウザ Chromium / Chrome
言語 JavaScript / TypeScript
特徴 Chrome操作に特化、拡張機能対応

Playwrightの前身とも言えるツールで、こちらも拡張機能の読み込みが可能です。

Cypress

フロントエンドテストで人気のツールです。

項目 内容
対応ブラウザ Chrome / Firefox / Edge
言語 JavaScript / TypeScript
特徴 デバッグしやすい、リアルタイムリロード

ただし、Chrome拡張機能のテストは公式にはサポートされていません。
通常のWebアプリには強いですが、拡張機能のテストには向いていなさそうです。

Selenium

歴史のあるテスト自動化ツールです。

項目 内容
対応ブラウザ 主要ブラウザ全般
言語 Java / Python / JavaScript など多数
特徴 実績が多い、情報が豊富

拡張機能の読み込みも可能ですが、セットアップがやや複雑です。

比較まとめ

ツール 拡張機能対応 学習コスト おすすめ度
Playwright ◎ 低め ★★★
Puppeteer ◎ 低め ★★☆
Cypress △ 低め ★☆☆
Selenium ○ 高め ★★☆

Chrome拡張機能のテストという観点では、PlaywrightかPuppeteerが良さそうです。
今回はPlaywrightを試してみることにしました。

4. Chrome拡張機能のE2Eテスト、ここが難しい

調べていくうちに、拡張機能のテストは通常のWebアプリとは違う難しさがあることがわかりました。

通常のWebアプリとの違い

通常のE2Eテストは、こんな流れです：

　1. ブラウザを起動
　2. URLにアクセス
　3. 要素を操作してテスト

しかし、Chrome拡張機能の場合は：

　1. ブラウザを起動
　2. 拡張機能を読み込む ← ここが追加
　3. 対象サイトにアクセス
　4. 拡張機能が動作するのを待つ ← ここも追加
　5. 要素を操作してテスト

拡張機能特有のステップが増えます。

拡張機能特有の課題

課題1：拡張機能の読み込み方法

Playwrightで拡張機能を読み込むには、ビルド後のフォルダパスを指定する必要があります。
開発中のソースコードではなく、manifest.jsonがあるフォルダを正しく指定しないと動きません。

課題2：コンテンツスクリプトのタイミング

まず、コンテンツスクリプトについて簡単に説明します。

Chrome拡張機能は主に3つの部分で構成されています：

名前 役割 例
バックグラウンドスクリプト 裏側で常に動いている データの保存、API通信
ポップアップ アイコンをクリックすると出る画面 設定画面、ログイン画面
コンテンツスクリプト 開いているWebページに直接入り込む ページにボタンを追加、表示を変更


「速いもん」の場合、不動産サイトを開くとページ内にボタンや機能が追加されますよね。
これがコンテンツスクリプトの仕事です。

なぜテストが難しいのか？

通常のWebサイトのテストでは、こんな流れです：

　1. ページを開く
　2. ページが読み込まれる
　3. すぐに要素を操作できる

しかし、拡張機能の場合は：

　1. ページを開く
　2. ページが読み込まれる
　3. 拡張機能がページを検知する
　4. コンテンツスクリプトが実行される
　5. ボタンなどの要素が追加される
　6. やっと要素を操作できる

つまり、ページが表示されても、拡張機能のボタンはまだ存在していない瞬間があります。

このタイミングでテストを実行すると「要素が見つからない」というエラーになります。
適切な待機処理を入れる必要があり、これが意外と難しいポイントです。

課題3：拡張機能のコンテキスト

拡張機能はバックグラウンド、ポップアップ、コンテンツスクリプトなど複数のコンテキストで動きます。
どのコンテキストをどうテストするか、設計が必要です。

課題4：認証の問題

弊社の拡張機能はログインが必要です。
テスト実行時に毎回ログインするのか、セッションを保持する方法があるのか、検討が必要です。

5. Playwrightで試してみた（そしてハマった）

実際にPlaywrightで拡張機能のテストを試してみました。

セットアップ

まず、Playwrightをインストールします。

npm init playwright@latest


拡張機能を読み込む設定

playwright.config.ts に拡張機能を読み込む設定を追加します。

ポイントは launchOptions.args に拡張機能のパスを指定することです。

import { defineConfig, devices } from '@playwright/test';
import path from 'path';

export default defineConfig({
  testDir: './tests',
  fullyParallel: true,
  reporter: [['list']],
  workers: 1,
  timeout: 30000,

  use: {
    headless: false,
    launchOptions: {
      slowMo: 10000,
      args: [
        // 拡張機能を読み込む設定
        `--disable-extensions-except=${path.join(__dirname, 'extension')}`,
        `--load-extension=${path.join(__dirname, 'extension')}`,
      ],
    },
  },

  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
  ],
});


設定のポイント

  • --disable-extensions-except：指定した拡張機能以外を無効化
  • --load-extension：拡張機能を読み込む
  • path.join(__dirname, 'extension')：プロジェクトルートの extension フォルダを指定
  • slowMo: 10000：動作を遅くしてデバッグしやすくする


そしてエラー...

実行してみると、こんなエラーが表示されました。

次の場所から拡張機能を読み込むことができませんでした: /Users/xxxx/Desktop/playwright-demo/extension. マニフェストファイルが見つからないか読み取れません


原因と対策

指定したフォルダに manifest.json が存在しない、またはパスが間違っていました。

拡張機能を読み込むには、以下のようなフォルダ構成が必要です：

  • playwright-demo/（プロジェクトルート）
    • playwright.config.ts
    • extension/ ← このフォルダに
      • manifest.json ← これが必要！
      • background.js
    • tests/


気づき！！

  • 拡張機能のパスは正確に指定する必要がある
  • 開発用のソースではなく、ビルド済みのフォルダを使う
  • manifest.json があるディレクトリを指定する

現在、正しいパスの設定を試みている段階です。

6. 今後の方針

まだ道半ばですが、今後の方針をまとめます。

直近でやること

  1. 拡張機能の正しいパスを特定する

    • ビルド後のフォルダ構成を確認
    • manifest.jsonの場所を把握

  2. まずは拡張機能の読み込みを成功させる

    • エラーを解消して、拡張機能が読み込まれた状態を作る

  3. シンプルなテストから始める

    • いきなり全機能ではなく、1つの機能だけテストする


将来的にやりたいこと

  • ログイン処理の自動化（セッション保持）
  • 複数サイトでのテスト実行
  • CI/CDへの組み込み（GitHub Actionsなど）


参考にしている情報


拡張機能のE2Eテストは情報が少ないので、成功したらまた記事にしたいと思います！

まとめ：自動化と手動テストのバランス

自動化すれば全て解決、というわけではありません。

自動テストには、こんな限界があります：

  • 自動化したテスト自体が正しいかどうか、誰が保証するのか？
  • テストコードにバグがあれば、問題を見逃してしまう
  • 想定外のケースは、そもそもテストに含まれていない


一方、手動テストには自動テストにはない強みがあります：

  • 人間の目で見て「なんか変だな」と気づける
  • 想定外の動きや違和感を発見できる
  • ユーザー視点での確認ができる


だからこそ、自動テストと手動テストを組み合わせることが大切だと思っています。

テストの種類 得意なこと
自動テスト 繰り返しの確認、リグレッションテスト、時間短縮
手動テスト 想定外の発見、ユーザー視点の確認、最終チェック


自動テストで「毎回やる定型的な確認」を効率化し、手動テストで「人間にしかできない確認」を行う。
このバランスを取ることで、品質を担保しながら効率化できるのではないかと考えています。

まだ自動化への道半ばですが、このバランスを意識しながら進めていきたいと思います！

7. おわりに

ここまで記事を読んでいただきありがとうございました！

弊社では現在エンジニアを募集しています！
この記事を読んで少しでも興味を持っていただけた方、ぜひカジュアルにお話ししましょう！

iimon採用サイト / Wantedly

以上、アドベントカレンダー6日目の「奥島」でした！

明日のアドベントカレンダー担当は「たっくーさん」です！
たっくーさんはiimon随一のイケメンで、友達思いでとにかく紳士的な方です。
その人柄の良さは社内でも評判で、きっとコードも紳士的で美しいに違いない...！

そんなたっくーさんがどんな記事を書いてくれるのか、楽しみです！
7日目よろしくお願いします〜！！