🏃‍♂️

Cucumber + PlaywrightのE2EテストをGitHub Actions経由で実行

2025/05/07に公開

 📘 この記事で分かることCucumber + Playwright を使った E2E テストの全体像
GitHub Actions による CI 連携の方法
実際の失敗ケースを作って動作を確認する流れ
自動化導入時の注意点とポイント

 🎯 対象読者Cucumber + Playwright を既に導入しているが、CI 連携が未完了の方
開発チームに E2E を根付かせたいリードエンジニア
PR 作成時などに自動でテストを走らせたい人
手動テストの限界に悩むスタートアップ開発者

 1. はじめにE2E テストを書いたけれど、手動実行のままでは品質を守りきれない ──。

そんな課題を解決するのが CI/CD との統合です。
中でも GitHub Actions は GitHub リポジトリとスムーズに連携でき、無料枠もあるため小〜中規模プロジェクトに最適。この記事では、Gherkin から ChatGPT でコードを自動生成した E2E テストを、GitHub Actions 上で動かすまでの流れを解説します。

 2. まずは動かしてみる最速で試すには、以下のリポジトリを fork し、GitHub Actions を有効にしてください。
https://github.com/moksahero/bdd-login-app
fork 後、「Actions」タブから "Run Login E2E" を実行
数分で以下のように成功表示されれば OK



 3. GitHub Actions の仕組みを見てみよう使用している Workflow ファイルは .github/workflows/login_e2e.yaml にあります。各行のアクションにコメント入れてみました。
name: Run Login E2E

on:
  workflow_dispatch: # ← これが手動実行を可能にする
  push: # ← コードがpushされたとき（任意でブランチ指定可）
    branches:
      - main
  pull_request: # ← PRが作成・更新されたとき
    branches:
      - main

jobs:
  e2e:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code # ← コードのチェックアウト
        uses: actions/checkout@v3

      - name: Setup Node.js #← NodeJSのインストール
        uses: actions/setup-node@v3
        with:
          node-version: "18"

      - name: Install dependencies in root directory
        #⇑ CucumberとPlaywrightなどのコードのインストール
        run: npm install && npx playwright install --with-deps

      - name: Install frontend dependencies and run
        #⇑ Next.jsのfrontendのコードのインストールと実行
        working-directory: ./frontend
        run: npm install && npm run dev &

      - name: Install backend dependencies and run
        #⇑ Expressのbackendのコードのインストールと実行
        working-directory: ./backend
        run: npm install && npm run start &

      - name: Run tests
        #⇑ Frontendが立ち上がるのを待って、Cucumberを実行する
        run: |
          npx wait-on http://localhost:3000/login
          npx cucumber-js

 4. テストをわざと失敗させてみるテストの信頼性を確かめるため、意図的に失敗させてみましょう。

 ブランチ作成と修正$ git checkout -b broken_backend
backend/src/index.ts の中を以下のように変更します：
if (email === "test@example.com" && password === "password123456") {
これで login.feature のシナリオと一致しないため、テストが失敗する状態になります。

 プッシュ & PR 作成$ git commit -am 'add to break test code'
$ git push origin HEAD
GitHub 上で PR を作成しましょう。
PR を作成すると、以下のようにテスト失敗が確認できます。

 5. テストが通るように戻してみる先ほど変更したパスワードを元に戻しましょう：
if (email === "test@example.com" && password === "password123") {
再度コミットしてプッシュします：
$ git commit -am 'fix to pass a test'
$ git push origin HEAD
すると PR 上でもテストが通ったことが確認できます：



 ✅ これでマージ可能に！CI によって E2E テストが自動で検証されることで、安心してコードレビュー・マージができる環境が整いました。

 6. まとめE2E テストは「書くだけ」では意味がありません。

GitHub Actions に組み込むことで、初めて日々の開発サイクルで活きてきます。
今回紹介した構成はシンプルなものでしたが、以下のような拡張も可能です：
Slack / Discord などへの通知連携
デプロイ前にテスト通過を必須とする条件付け
複数ブラウザ・OS 環境でのクロステスト
まずは 1 つのテストから始めて、自動化の恩恵をチームに取り入れてみてください。

 👨‍💻 著者について東京とアムステルダムを拠点に活動中。

東欧・南アジアのエンジニアと連携しながら、QA コンサル・テスト自動化・フルスタック開発・PM 業務まで幅広く担当しています。
Cucumber・Playwright・ChatGPT などを活かした効率的なテスト運用や開発基盤づくりのご相談も歓迎です！

📘 この記事で分かること

🎯 対象読者

1. はじめに

2. まずは動かしてみる

3. GitHub Actions の仕組みを見てみよう

4. テストをわざと失敗させてみる

ブランチ作成と修正

プッシュ & PR 作成

5. テストが通るように戻してみる

✅ これでマージ可能に！

6. まとめ

👨‍💻 著者について

Discussion