E2Eテストで深夜2時に泣くのはもう終わりにしよう：Playwrightによる「守り」の自動化術

E2Eテストで深夜2時に絶望したことはあるか？ 俺はある。
リリース直前に「決済ボタンが押せない」という致命的なバグを叩きつけられ、結局、本番環境で震えながら全画面を手動ポチポチする羽目になったあの夜。あれは二度とごめんだ。

巷の技術記事は「テスト設計の哲学」だの「Page Object Modelの極致」だの、小難しいことを並べ立てすぎていて吐き気がする。個人開発やスタートアップの現場でそんな重厚な設計は不要だ。
Playwrightの本質は、「人間がブラウザを触る動作をそのままコードに落とし込む」こと。これに尽きる。

1. 複雑な設定は全部捨てろ

まずは基本のテストコードを見てくれ。これだけで十分だ。

// tests/login.spec.js
import { test, expect } from '@playwright/test';

test('ログインしてダッシュボードが見れるか', async ({ page }) => {
  await page.goto('/login');
  // セレクタはCSSクラスじゃなく data-testid を使え。デザイン変更でテストが死ぬ悲劇を防ぐ唯一の策だ
  await page.getByTestId('email-input').fill('[email protected]');
  await page.getByTestId('password-input').fill('password123');
  await page.getByRole('button', { name: 'ログイン' }).click();

  await expect(page).toHaveURL(/.*dashboard/);
  await expect(page.getByRole('heading')).toHaveText('Welcome back');
});

「待機時間は？ `sleep`は？」と思った奴は、Seleniumの呪縛に囚われている。Playwrightは自動待機（Auto-waiting）が優秀すぎて、明示的な`sleep`を書いたら負けだ。要素が表示されるまで勝手に待ってくれる。これを知った時、俺は思わず「マジかよ」と声が出た。

2. 泥臭い壁：認証（ログイン状態）の保持

テストのたびにログイン処理を書くのはナンセンスだ。テストが10個あれば10回ログインするのか？ 無駄すぎる。
現場で最もハマるのがこの「認証情報の管理」だ。`storageState`を使えば、ログイン後のセッションをファイルに保存し、それを使い回せる。

// playwright.config.js
module.exports = {
  use: {
    // ログイン状態を保存・再利用して爆速化する
    storageState: 'state.json',
  },
};

これで、毎回ログイン画面を経由せず、いきなりダッシュボードからテストを開始できる。これが「実戦」の知恵だ。

3. GitHub Actions：CIのスペックはケチるな

ローカルでは動くのにGitHub Actionsでだけ落ちる。この現象に3日間溶かした俺の教訓を教える。原因の9割は「画面サイズ」と「リソース不足」だ。

# .github/workflows/e2e.yml
name: Playwright Tests
on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always() # テストが落ちてもレポートを確実に残す
        with:
          name: playwright-report
          path: playwright-report/

`actions/checkout@v4` を使え。古いバージョンはもう捨てろ。そして、メモリの少ないインスタンスで無理やり動かすと、ブラウザがランダムにクラッシュして発狂することになる。CIの実行時間は「開発者の寿命」だ。ケチるな。

4. 拡張性との付き合い方

「Page Object Model（POM）はいつ導入すべきか？」
答えはシンプル。「テストコードのコピペが3回発生した時」だ。
最初はベタ書きでいい。複雑なフレームワークを組むのは、テストが1000個を超えてから考えれば十分。まずは「動く」という事実を積み上げるのが先決だ。

5. E2Eテスト＝ビジネス価値への投資

「テストを書く暇があったら新機能を実装したい」。その気持ちは痛いほどわかる。だが、デプロイボタンを押した瞬間に決済機能が死んでいることに気づいた時の冷や汗は、二度と味わいたくないはずだ。

E2Eテストは完璧を目指すものじゃない。「クリティカルな動線だけは絶対に死なせない」ための保険だ。

自動テストがあれば、デプロイの心理的障壁が消える。
「壊してもCIが教えてくれる」という安心感は、開発速度を劇的に加速させる。自信を持ってコードをマージし、堂々とリリースする。そのために俺たちはテストを書くんだ。

結局のところ、E2Eテストは「書く」んじゃない。「ブラウザに代行させて、俺たちはもっと大事な仕事をする」のが正解だ。

さあ、今すぐ `npx playwright codegen` を叩いて、最初のテストを自動生成しろ。君の夜を取り戻すのは、今のその一行から始まる。