この記事はMagicPodアドベントカレンダー2025の23日目です
1. はじめに
E2E（End-to-End）テストは、ユーザー視点でアプリ全体の動作を確認するうえで欠かせない工程です。
MagicPodは、そんなE2Eテストをノーコードで簡単に作成できる強力なツールですが、実行時間が長くなりやすいという特性があります。
とくに「コード更新（push）のたびにMagicPodを自動実行する構成」にしていると、以下のような問題が発生しやすくなります。
- テストが増えるほど実行時間が伸び、pushのたびに開発ペースが中断される
- 小さな修正でもE2Eテストが走り、毎回テスト完了を待つことになる
- 結果として push → E2E実行 のサイクルが重く、担当者が“テスト待ち”中心になってしまう
実際の現場でも、こんな声がよく聞かれます。
「pushのたびにMagicPodが動き出し、毎回20〜30分待たされて開発リズムが崩れる…」
「細かい修正ごとにE2Eが走るので、CI/CD全体が重くなる…」
この記事では、この課題を解決するために
MagicPodとGitLab CIを連携して “通常開発からE2E実行を切り離す” 運用方法を紹介します。
MagicPodについて：https://magicpod.com/
2. MagicPodのE2Eが開発を止めてしまう理由
MagicPodはノーコードでE2Eテストを作れる強力なツールですが、
実行に時間がかかりやすい構造を持っているため、運用次第では開発フローを止めてしまうことがあります。
MagicPodで実行時間が伸びる理由
MagicPodのテストは、1テストケースが複数のUI操作ステップ（クリック・入力・画面遷移など）の集合で構成される仕組みになっています。
そのため、テストケース数に加えて、1ケースあたりのステップ数が増えるほど累積実行時間が伸びやすくなるという性質があります。
さらに、実ブラウザを操作するE2Eテストでは、次の要因が実行時間に影響します。
- ステップ数の増加 = 実行時間が比例して増加
- 実ブラウザ操作のため、ネットワーク/API応答時間に影響される
- UIレンダリングの変動で微妙な待ち時間が発生する
目安としては次の通りです。
| ステップ数 | 実行時間（目安） |
|---|---|
| 50 steps | 1〜2分 |
| 100 steps | 3〜5分 |
| 200 steps | 6〜10分 |
| 300 steps | 10〜15分 |
そして、これらが テストケースの本数分積み重なります。
テストケースが20〜40本ある場合、すべて実行すると平気で30分〜1時間かかることも。
pushとE2Eが紐づくと何が起きるのか？
多くのプロジェクトでは、pushを契機にCIが自動で動きます。
軽量なユニットテストまでなら良いのですが、E2Eは本質的に実行時間が長く、pushトリガーとの相性が良くありません。
push（5秒前）
↓
CIでMagicPod実行開始
↓
完了まで20〜30分…
↓
開発者「作業が止まってしまう…」
push回数が多いほど影響は拡大
- アジャイル開発でコミット回数が多い
- 複数メンバーが同時にpushする
- フロントエンド中心で変更が頻繁
こういったプロジェクトでは、E2EがCIのボトルネックとなり、開発リズムが乱れるという問題が顕著になります。
3. CI × MagicPodで解決するアプローチ
そこで有効なのが、通常開発（push）ではMagicPodを動かさず、E2Eは別ジョブとして定期/手動実行に分離するという構成です。
Before：コード更新のたびにE2Eが走る
push → MagicPod実行 → 20分待ち
After：開発フローとE2Eを切り離す
push → 軽量テストのみ（Lint/Unit/Build）
E2E → 1日1回のスケジュール / 必要な時だけ手動実行
開発リズムが崩れず、CI/CD全体も軽量化できる構成が実現します。
4. 全体構成イメージ
MagicPodをCIと連携して運用する際の全体像を、以下の図にまとめました。
pushトリガーでの通常CIパイプライン（ビルド・ユニットテスト・パッケージなど）は軽量化し、
アプリの実行およびMagicPodのE2Eテストはスケジュール or 手動実行でのみ実行されるように分離します。
この構成にすることで、pushのたびにE2Eテストが走ることがなくなり、
開発リズムを維持しつつ、E2Eテストを確実に回す運用が実現します。
5. MagicPod側での準備
- テストシナリオを作成
- APIキーを取得（CIの変数に保存）
- テスト対象環境の整備（MagicPodからアクセスできる環境）
6. GitLab CI の設定例
MagicPodの実行は「スケジュール or 手動」のみに絞り、pushでは実行しません。
stages:
- test
magicpod:
stage: test
script:
- xvfb-run ./magicpod-command-line --magic_pod_config="./magic_pod_config.json"
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"' # 自動実行
- if: '$CI_PIPELINE_SOURCE == "web"' # 手動実行
GitLabの スケジュール（cron） を設定することで、毎日自動でE2Eテストが走る仕組みが完成します。
参考：
- CircleCIとの連携 ※Gitlab CIはCircleCIと同様の手順で実装可
- コマンドライン一括テスト実行（ローカルPC環境）
7. テスト自動化によるメリットまとめ
| 課題（Before） | 解決後（After） |
|---|---|
| pushのたびにE2Eが走り開発が止まる | pushでは軽量テストのみ |
| MagicPodの長時間待ち | 開発者が待たなくてよい |
| Runnerが占有されCIが渋滞 | CI/CD全体が高速化 |
| 手動実行の属人化 | スケジュール実行で安定回転 |
8. メール通知で異常をすぐ検知
毎日テスト結果をメール通知することで、
失敗したテストをいち早く発見し、問題個所を速やかに特定できる運用が可能になります。
テストが成功したか失敗したか、どのシナリオで異常が起きたのかが一目で分かります。
例えば、以下のような通知が届きます。
Result (total 24 test cases)
Unresolved: 1
Unresolved test case:
#8 Visual differences detected
(diff rate: 0.0213%, threshold: 0.01%)
このように、MagicPod による E2E テストの結果がメールで即時共有されることで、
異常の早期発見・対応のスピード向上・属人化防止につながります。
9. 安定運用のTips
- 深夜 or 朝イチに定期実行を設定
- UI変更時はシナリオをこまめに調整
- 共通ステップをライブラリ化してメンテ楽に
- フレーク（不安定）テストは優先的に改修
10. まとめ
MagicPodはE2Eテストを簡単に作れる一方で、実行時間が長くなりがちです。
しかし、GitLab CIと連携し、日常開発とE2E実行を分離する構成を取ることで、
- 開発者が待たない
- CI/CD全体が軽量化する
- 障害の早期検知ができる
- 属人化しないテスト基盤が作れる
というメリットを得られます。
MagicPodは、CIと組み合わせることで “継続的に運用できるE2Eテスト基盤”へ進化 します。