手動テストで消耗するな：PlaywrightによるE2E自動化とCI/CDパイプライン構築の全技術
「リリース前の画面ポチポチ」に、あと何時間ドブに捨てる気だ？
デプロイボタンを押す直前、震える手でログイン画面を確認し、カートに商品を入れて決済フローを確認する。そんな作業を繰り返している間に、コードの価値は陳腐化し、お前の貴重な脳のリソースは浪費されている。
俺もかつてはそうだった。「テストコードを書く余裕がない」という死のループに陥り、深夜のデプロイでバグを仕込んで青ざめる日々。だが、Playwrightを導入してからは景色が変わった。今回は、泥臭い手動テストから脱却し、CI/CDで「寝ている間に品質が担保される」環境を作るための、実戦的な勘所を共有する。
1. 認証の「思考停止」を捨て、状態を再利用せよ
多くのエンジニアが犯す最大の過ちは、すべてのテストケースで「ログイン」から書き始めることだ。これではテスト実行時間が線形に増大し、結果として誰もテストを回さなくなる。
`storageState`を使い、ブラウザのCookieとLocalStorageを保存・ロードするのが鉄則だ。
// playwright.config.ts
import { defineConfig } from '@playwright/test';
export default defineConfig({
use: {
// 認証済み状態を再利用
storageState: 'playwright/.auth/user.json',
},
});
⚠️ セキュリティへの注意喚起
`storageState`に保存されるJSONには、セッション情報やトークンが含まれる。絶対にGitの管理下に置くな。 `.gitignore`に`.auth/`を追加し、CI環境ではログインテストを一度だけ実行してArtifactとして受け渡す運用が必須だ。トークンの期限切れ（リフレッシュ戦略）については、テスト開始時に`globalSetup`でログインチェックを走らせる実装を推奨する。2. 「待ち」のコードを捨て、宣言的に記述する
`page.waitForTimeout(3000)`と書いた瞬間、そのテストコードは「ゴミ」に成り下がる。ネットワークの揺らぎやレンダリングの遅延を「祈り」で解決しようとするな。
Playwrightの強力なオートウェイトを信じろ。
// 悪い例：3秒待つという「祈り」
await page.waitForTimeout(3000);
await page.click('.submit-btn');
// 良い例：状態が変わるまで待機する「宣言」
const button = page.locator('.submit-btn');
await expect(button).toBeVisible();
await button.click();
人間が「これくらい待てばいい」と考えるのは、計算機科学の観点から見れば極めて非論理的だ。要素の出現、非表示、ネットワークのアイドル状態をトリガーにすべきだ。
3. CI環境の「罠」：環境差分をコードで埋める
ローカルで動くのにGitHub Actionsで落ちる。この現象の正体は、ほとんどの場合「環境の不一致」だ。タイムゾーン、スクリーンサイズ、フォントのレンダリング。これらを放置しているなら、お前のCIはテストではなく「ガチャ」を回しているに過ぎない。
# .github/workflows/playwright.yml
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Playwright
run: npx playwright test
env:
TZ: Asia/Tokyo # タイムゾーン固定
CI: true
- name: Upload Report
if: always() # 失敗してもレポートを保存
uses: actions/upload-artifact@v4
with:
name: playwright-report
path: playwright-report/
retention-days: 7
失敗時のトレースを捨ててはいけない。 `playwright-report`には、失敗した瞬間のDOMスナップショットや動画が記録される。これがあれば、深夜のデバッグで「なぜ落ちた？」と悩む時間はゼロになる。
4. 成長のための「次のステップ」
テスト自動化は、単なる作業効率化ではない。「バグを恐れず、大胆にリファクタリングする権利」を手に入れるための投資だ。
今のコードにテストがないのなら、まずは「ログインしてマイページに遷移する」というたった1つのケースから始めろ。完璧を目指す必要はない。昨日より1つだけ、自動化された箇所が増えればいい。
学習リソース
- Playwright 公式ドキュメント - まずはここを熟読しろ。
- Testing Library - 「ユーザーの視点」でテストを書くための哲学を学べ。
明日から手動テストで消耗するのはやめろ。コードで眠れ。