テスト自動化のためのGitHub Actions：完全セットアップガイド

Yunhao Jiao
テスト自動化のためのGitHub Actions：完全セットアップガイド カバー

GitHub Actionsは現代のソフトウェアチームに最も広く使用されているCI/CDプラットフォームであり、GitHub Actionsで自動テストをセットアップすることは、最もレバレッジの高い品質投資の一つです。すべてのPRに対して自動的に実行され、問題のあるマージをブロックし、手動トリガー不要で開発者に迅速なフィードバックを提供するテスト——これがGitHub Actionsが実現するものです。

このガイドでは、基本的なテストランナーから本番グレードのテスト自動化パイプラインまで、完全なセットアップを解説します。

コアコンセプト

GitHub ActionsのワークフローはYAMLファイルで、`.github/workflows/`に配置し、実行タイミングと実行内容を定義します。テスト自動化における主要なコンセプトは以下の通りです：

トリガー：ワークフローはいつ実行されるか？

  • `push` — ブランチへのコミットのプッシュ時
  • `pull_request` — すべてのPR時（品質ゲートとして最も重要）
  • `schedule` — cronスケジュールによる実行（本番環境の監視用）
  • `workflow_dispatch` — 手動トリガー

ジョブ：何が実行されるか？各ジョブは独立した実行環境です。

ステップ：ジョブ内のコマンドとアクションの順序付きリスト。

環境とシークレット：機密情報（APIキー、データベースURL）はワークフローファイルではなく、GitHubシークレットに保存されます。

基本的なテスト自動化のセットアップ

Node.js プロジェクト向けの、最小限かつ完全なワークフロー：

このワークフローは main または develop へのすべての PR で実行され、テストスイートを実行し、カバレッジレポートをアーティファクトとしてアップロードします。

E2E テストの追加

E2E テストには実行中のアプリケーションが必要です。Next.js やその他のフレームワークアプリケーションをプレビュー環境にデプロイしている場合、最も堅牢なアプローチはプレビューデプロイメント URL に対してテストを実行することです：

あるいは、ローカルで実行する Playwright ベースの E2E テストの場合：

PR ステータスチェックとブランチ保護

テストが品質ゲートとして機能するのは、失敗時にマージをブロックする場合のみです。GitHub で以下のように設定してください：

  1. 「Settings → Branches → Branch protection rules」に移動する
  2. main（および該当する場合は develop）にルールを追加する
  3. 「Require status checks to pass before merging」を有効にする
  4. ワークフロージョブを必須チェックとして追加する
  5. 「Require branches to be up to date before merging」を有効にする

設定が完了すると、テストが失敗した PR はレビュアーの承認に関わらずマージできなくなります。

テストの並列化

テストスイートが大きくなるにつれて、順次実行は遅くなります。GitHub Actions は並列ジョブをサポートしています：

これにより 4 つの並列テストジョブが実行され、それぞれがテストスイートの 4 分の 1 を実行します。合計実行時間はシャード数で割られます（若干のオーバーヘッドあり）。

TestSprite GitHub App：ゼロ設定の代替手段

YAML 設定なしですべての PR に自動 E2E テストを導入したいチームには、TestSprite の GitHub App がよりシンプルな方法を提供します：

  1. リポジトリの設定から TestSprite GitHub App をインストールする
  2. TestSprite ダッシュボードでプレビューデプロイメント URL を設定する
  3. すべての PR で自動的にフルテストスイートがプレビューデプロイメントに対して実行される
  4. 結果は PR チェックとして表示され、テストが失敗するとマージがブロックされる

YAML 不要、ランナー設定不要、アーティファクト管理不要。エージェント型テストがカバレッジの生成、実行、レポーティングを自動的に処理します。

スケジュール実行による本番環境のモニタリング

PR テストに加え、本番環境に対するスケジュール実行により、デプロイ以外で発生する問題を検知できます：

これにより、スモークテストが 30 分ごとに本番環境に対して実行され、デプロイ間でクリティカルなフローが失敗した際にアラートを発します。

TestSprite で GitHub Actions テストをセットアップする →