PlaywrightでE2Eテストを書き始めたら、フロントの壊れに気づくのが早くなった話

🙌 結論から

Playwright を導入したことで、フロントエンドの主要な画面遷移・フォーム送信が壊れていないかを自動で確認できるようになりました(^o^)/

手動で画面を開いて確認していた作業が自動化されたことで、デプロイ後の心理的な負担がかなり減っています。

セットアップは思っていたより簡単で、初回の npx playwright test まで10分もかかりませんでした！

💡 Playwright を選んだ理由

以前は Cypress を使っていたことがあったのですが、設定が重めだったり TypeScript との相性がいまいちだったりと、個人的にはあまり馴染めませんでした(´･ω･`)

Playwright は Microsoft が開発している E2E テストフレームワークで、クロスブラウザ対応・TypeScript 完全サポート・ヘッドレス実行が標準で揃っています！

特に気に入ったのが、テストコードが直感的に書けることです。

ブラウザの操作をほぼそのまま関数に落とし込む書き方なので、慣れるまでの時間がかなり短かったです。

Cypress と違い、ブラウザプロセスをフレームワーク外から直接動かす仕組みなので、複数ブラウザでの並列実行もスムーズです。

👀 最初のテストを書いてみる

インストールはワンコマンドです。

npm init playwright@latest

対話形式でブラウザ・フォルダ・CI 対応などを設定した後、サンプルテストが自動生成されます！

基本的なテストはこういう感じです。

import { test, expect } from '@playwright/test'

test('ログイン画面にアクセスできる', async ({ page }) => {
  await page.goto('/login')
  await expect(page.getByRole('heading', { name: 'ログイン' })).toBeVisible()
})

test('ログインフォームを送信できる', async ({ page }) => {
  await page.goto('/login')
  await page.getByLabel('メールアドレス').fill('test@example.com')
  await page.getByLabel('パスワード').fill('password123')
  await page.getByRole('button', { name: 'ログイン' }).click()
  await expect(page).toHaveURL('/dashboard')
})

getByRole や getByLabel などの セマンティクスベースのセレクター が用意されているので、#login-form > input[type="text"] みたいな壊れやすいセレクターを書かなくて済みます(^^)

CSS セレクターではなくアクセシビリティ属性を使うので、マークアップの実装詳細が変わっても壊れにくいテストになっています。

✨ 導入してみた感想

一番ありがたかったのは、「デプロイ後に画面が白くなっていた」みたいなエラーを自動で検知できるようになったことです。

以前はそういうミスを手動確認のときに見つけていたのですが、PR のたびに Playwright が走ることで、マージ前に気づける仕組みになりました！

--reporter=html オプションで HTML レポートが出るので、失敗したテストの画面キャプチャと実行ログがセットで確認できます。

どのステップで壊れたかが一目でわかるので、デバッグのコストがかなり下がりました🔥

ローカルで npx playwright test --headed を実行すると、実際のブラウザが操作されている様子が見えます。

慣れるまでの入門用としても使いやすく、テストが何をやっているかを視覚的に確認できるのがかなりわかりやすいです！

👍 まとめ

Playwright は フロントエンドのテストを書く入口として、今一番おすすめできるツールです(｀・ω・´)

セットアップが速く、TypeScript との相性もよく、HTML レポートまで揃っているので、「フロントのテストを書いたことがない」というプロジェクトへの導入にも向いています。

手動で確認していた画面遷移を自動化するだけで、デプロイ後の確認コストがかなり変わります。

まだフロントエンドのテストが手動確認頼みのプロジェクトがあれば、ぜひ一度試してみてください！