投稿者: 
GitHub Actions上でテストを実行するっていうのをやってみたくて。
Playwright導入時に下記聞かれてyesにしていたんだけど、自動的にymlも生成してくれていて勝手にできてた。（なので実質自分では何もしてない）
✔ Add a GitHub Actions workflow? (y/N) · trueymlファイルの中身
初期設定は下記となっている。
name: Playwright Tests
on:
push:
branches: [ main, master ] // push → main または master ブランチにプッシュされたとき
pull_request:
branches: [ main, master ] // pull_request → 同じブランチに対して PR が作成されたとき
jobs:
test:
timeout-minutes: 60 // 60 → 1時間でタイムアウト
runs-on: ubuntu-latest // ubuntu-latest → 最新の Ubuntu 環境で実行
steps:
- uses: actions/checkout@v4 // GitHubリポジトリのコードを runner（Ubuntu 仮想マシン）に取得します
- uses: actions/setup-node@v4
with:
node-version: lts/* // Node.js の LTS バージョンをインストール、PlaywrightはNode.js上で動作するため必須
- name: Install dependencies // package.json にある依存パッケージを正確にインストール
run: npm ci // npm ci は CI用で高速かつクリーンインストール
- name: Install Playwright Browsers // Chromium、Firefox、WebKit など必要なブラウザをインストール
run: npx playwright install --with-deps // Linuxに必要なライブラリも同時にインストール
- name: Run Playwright tests // Playwright のテストを実行、デフォルトでは headless モードで動作
run: npx playwright test
- uses: actions/upload-artifact@v4
if: ${{ !cancelled() }} // workflowがキャンセルされていない場合のみ実行
with:
name: playwright-report
path: playwright-report/ // テスト結果を保存
retention-days: 30 // GitHub上に残す日数これ、↑ymlの中身見てて初めて気づいたんだけど、テスト結果をレポートとしてhtmlで保存してくれてるんだ。（保存期間は設定する必要あり）
ローカル（/playwright-report/index.html）にもレポートは作成されているのだけどこれはテスト走らせるごとに上書きされていってるっぽい。
ちなみに失敗時。↓
CICDでテストを走らせるメリット
chatGPTに聞きました。
①コード変更時に自動で実行される
- GitHub Actions の workflow では、push や pull_request に連動して自動実行できます
- ローカルで実行し忘れても、CI が勝手にテストしてくれる
- 例：
- チームメンバーが PR を作ったときに自動でテストが走る
- マージ前に失敗したら警告 → バグを本番に入れにくい
②環境を統一できる
- CI は Ubuntu / Windows / Mac などのクリーンな環境 で実行される
- ローカル環境は Node.js バージョンやブラウザ、OS に依存して結果が変わることがある
- CI で統一することで 環境差によるテストの失敗を減らせる
③チーム全体でテスト結果を共有できる
- CI 上で生成された playwright-report やスクリーンショットは アーティファクトとして保存可能
- チームメンバー全員が確認できる
- ローカルだと自分の環境だけでしか確認できない
④過去のテスト結果を記録できる
- CI 上では各実行ごとに アーティファクトやログを保存
- 過去のテスト結果や失敗したケースを振り返ることができる
- ローカルだと消してしまいやすい
⑤自動化・デプロイとの連携
- CI/CD はテストだけでなく ビルド・デプロイの自動化 と組み合わせられる
- 例：
- テストに合格したらステージング環境にデプロイ
- 本番リリース前に全ブラウザでテストを通過するのを条件にする
逆にデメリット
- 環境がローカルと違う
ローカルでは成功しても、CI上（Ubuntuなど）で失敗することがある。 - デバッグがしにくい
失敗時に直接ブラウザを確認できず、ログやスクショ頼みになる。 - 設定・運用が少し手間
WorkflowやSecretsの設定、安定化などに時間がかかる。 - 外部依存に弱い
APIやネットワークに依存するテストはCI環境で不安定になりやすい。
たぶん運用するとなったら、ローカルでテストしてみて問題なければデプロイし、ダブルチェックのような形でCICDでも確認するという感じになるのかなと予想。テスト結果を記録できて共有できるのはいいなと思った。
c.sakyou