1. はじめに
こんにちは！iimonでフロントエンドエンジニアをしている「奥島」です！
前回の記事では、テスト自動化に向けてどのツールを使うかを調べました。
Playwright・Puppeteer・Cypress・Seleniumを比較して、最終的にPlaywrightを試してみた——という内容でした。
ツールは選んだものの、「何をどこまでテストすべきか」が全然決まっていませんでした。今回は、テスト自動化の方針をどう設計するかについて整理してみました。
2. 前回の記事のおさらい
前回はE2Eテスト自動化のツール比較をしました。
| ツール | 拡張機能対応 | 学習コスト | おすすめ度 |
|---|---|---|---|
| Playwright | ◎ | 低め | ★★★ |
| Puppeteer | ◎ | 低め | ★★☆ |
| Cypress | △ | 低め | ★☆☆ |
| Selenium | ○ | 高め | ★★☆ |
Chrome拡張機能のテストという観点でPlaywrightを選び、実際にセットアップまで試してみました。
ただ、自動テストと手動テストのバランスをどう取るか という疑問があったので調べました！
3. ツールを選んだ後に気づいたこと
「何をどこまで」が決まっていなかった
Playwrightのセットアップを進めながら、こんな疑問が出てきました。
「このボタンのクリックをテストする？」
「ページ遷移は？」
「エラー時の表示は？」
「全部E2Eで書けばいい？」
E2Eで書こうとすると、テストすべき項目が無限に出てきます。かといって全部書こうとすると、実行時間が膨大になる。
方針がないまま自動化するリスク
方針なしに自動化を進めると、こんなことが起きます：
- E2Eばかりになる：「とりあえず動作確認できるから」という理由でE2Eに寄りすぎる
- テストが遅くなる：E2Eは実行コストが高いので、増えるほどCIが重くなる
- 壊れやすくなる：UIの微妙な変更で大量のテストが落ちる
- 何を信頼すればいいかわからなくなる：テストが通っているのにバグが出る
自動化する前に、「どの層で何を守るか」を決めておく必要がある と感じました。
4. 方針設計、どこまで考えられるか
各層に何を書くかの判断基準
テストには大きく3つの層があります。
| 層 | 確認すること |
|---|---|
| ユニットテスト | 関数・クラスなど、部品ひとつひとつの動作 |
| 統合テスト | 複数の部品をつないだときの動作 |
| E2Eテスト | ユーザーが実際に操作する一連のシナリオ |
それぞれの層に「何を書くか」の判断基準を整理しました。
ユニットテストに書くもの
「外部（DBや画面）に触らずに完結する処理」が対象です。
- 値の計算・変換（金額の計算、日付のフォーマットなど）
- 入力値のバリデーション（必須チェック、文字数チェックなど）
- 条件分岐のロジック（〇〇のときは△△を返す、など）
統合テストに書くもの
「複数の部品をつないだときの動作」が対象です。ユニットテストは部品単体の確認ですが、統合テストは「つないだときにちゃんと動くか」を確認します。
拡張機能でいうと、バックグラウンドスクリプトとコンテンツスクリプトがメッセージをやりとりする部分が対象です。それぞれ単体では動いていても、「連携したときにうまく動くか」はユニットテストだけでは確認できません。
判断の目安は「2つ以上のモジュールをまたぐ処理かどうか」です。
E2Eテストに書くもの
「ユーザーが実際に操作するシナリオ」だけに絞ります。E2Eは信頼感が高い反面、実行に時間がかかって壊れやすいので、他の層で代替できる確認はE2Eに持ち込まない のが基本方針です。
具体的には「対応サイトを開いたとき、拡張機能のボタンが表示されるか」「ボタンを押したとき、正しく動作するか」など、ユーザーが体験する一連の流れだけを対象にします。
「この確認、ユニットテストでもできるのでは？」と感じたらE2Eには書かない、という判断を意識するようにしました。
まとめ
| 確認したいこと | どの層に書く？ |
|---|---|
| 計算・変換・バリデーションのロジック | ユニットテスト |
| 複数モジュールの連携・メッセージのやりとり | 統合テスト |
| ユーザーが操作する一連のシナリオ | E2Eテスト |
| 上のどれかで代替できる確認 | E2Eには書かない |
自動化できるもの・できないものの線引き
「自動化」と一言で言っても、すべてが自動化できるわけではありません。
自動化できること
- テストの実行（CIに組み込めば毎回自動で走る）
- カバレッジの計測（どのコードがテストされているか可視化できる）
- フレイキーなテストの検出（実行するたびに結果が変わる不安定なテストを見つける）
人間が判断すべきこと
- 何をテストするかの判断（仕様を理解していないと決められない）
- テストの優先順位付け（どのバグリスクが高いかは人間が判断しないと‥）
- テストコードの削除・修正判断（「このテスト、もう意味ないよね」は人間にしかわからない）
| 項目 | 自動化できる？ | 理由 |
|---|---|---|
| テストの実行 | ◎ | CIに組み込むだけ |
| カバレッジ計測 | ◎ | ツールがある |
| テストの優先順位付け | △ | 優先度はサービスの仕様を知っていないと決められない |
| 何をテストするかの判断 | △ | 仕様を理解していないと決められない |
| テストの保守・削除判断 | ✕ | 「もう不要」の判断は人間にしかできない |
「ツールを入れれば全部解決」ではなく、人間が判断すべき部分を先に固めてから自動化に進む のが正しい順番ではないかと思います！
実際に進める順番
実際にどの順番で進めるかも整理しました。
Step 1：ユニットテストから始める
E2Eより先に、ロジック部分のユニットテストを書きます。E2Eから始めると「なんでも全部E2Eで確認」する癖がつきやすいので、最初にユニットテストの習慣をつけるのが大事です。
Step 2：手動テストの手順書を整備する
E2Eテストを書く前に、「手動でどう確認しているか」を文章に残します。この手順書が、そのままE2Eテストのシナリオ設計に使えます。手順書なしにE2Eを書き始めると、「何を確認するテストなのか」が曖昧になりがちです。
Step 3：手順書をもとにE2Eテストを書く
Step 2で整備した手順書を見ながら、「本当にE2Eでないと確認できないもの」だけをPlaywrightで自動化します。
Step 4：CIに組み込む
ユニットテストとE2Eテストが揃ったら、CIに組み込んでプルリクのたびに自動実行されるようにします。まずはユニットテストだけでも組み込むと、フィードバックが早くなります。
5. 今後の方針
直近でやること
各層の判断基準をドキュメントとして残す
- 「この処理はどの層に書く？」と迷ったときに見返せるものを作る
まずユニットテストから書き始める
- 新しく実装する処理から少しずつユニットテストを追加していく
手動テストの手順書を整備する
- 現在手動でやっている確認内容を書き出して、E2Eシナリオの設計に備える
将来的にやりたいこと
- CIへの組み込み（まずはユニットテストだけでも自動実行する）
- E2Eテストの自動化（手順書をもとにPlaywrightでシナリオを書く）
- コントラクトテストの検討（バックグラウンドとコンテンツスクリプト間のメッセージの契約をテストで保証する）
まとめ：自動化と手動テストのバランス
自動テストには、こんな限界があります
- 自動化したテスト自体が正しいかどうか、誰が保証するのか？
- モックと実装がズレたとき、ユニットテストはそれを検知できない
- 想定外のケースは、そもそもテストに含まれていない
一方、手動テストには自動テストにはない強みがあります：
- 人間の目で見て「なんか変だな」と気づける
- 想定外の動きや違和感を発見できる
- ユーザー視点での確認ができる
| テストの種類 | 得意なこと |
|---|---|
| 自動テスト | 繰り返しの確認、リグレッションテスト、時間短縮 |
| 手動テスト | 想定外の発見、ユーザー視点の確認、最終チェック |
自動テストで「毎回やる定型的な確認」を効率化し、手動テストで「人間にしかできない確認」を行う。このバランスを取ることが、品質を担保しながら効率化する近道だと思っています。
6. おわりに
ここまで読んでいただきありがとうございました！
前回はツール選定の話でしたが、今回は方針設計の話を整理してみました。
最初は「ツールさえ決まれば自動化できる」と思っていました。でも実際に進めてみると、ツールより先に「何をテストするか」を決めることの方がずっと大事だったというのが今回の一番の気づきです。
方針が決まっていないままツールだけ入れても、E2Eだらけになったり、テストが増えるほど遅くて壊れやすくなったりと、むしろ負債が増えていく可能性があります。「自動化する前にまず方針を固める」という順番を意識するだけで、だいぶ変わってくると思います
弊社では現在エンジニアを募集しています！
ぜひカジュアルにお話ししましょう！
