はじめに
Laravel アプリの品質を安定させるには、ユニットテストや機能テストに加えて、画面を実際に操作する E2E テストも整えておきたいところです。ログイン、フォーム送信、権限制御、画面遷移などは、ブラウザ上で確認して初めて見つかる不具合も少なくありません。
Pest v4 では、Playwright ベースのブラウザテストが利用できるようになり、Laravel のテストヘルパーと組み合わせながら、実ブラウザに近い確認を行いやすくなりました。
Pest v4 ブラウザテストの特長
公式ドキュメントでも、Pest のブラウザテストは Laravel のテスト API と自然に組み合わせられる点が強みとして案内されています。
- モデルファクトリや
RefreshDatabaseを活用しやすい - 実ブラウザでクリック、入力、画面遷移を確認できる
- モバイルやダークモードなど表示条件も試しやすい
- Playwright ベースで高速かつ安定しやすい
従来のブラウザテストと比べて、テストコードの読みやすさと、Laravel 側のヘルパーとの親和性が高い点が扱いやすさにつながります。
セットアップ
導入の基本は次のとおりです。
composer require pestphp/pest-plugin-browser --dev
npm install playwright@latest
npx playwright install
Laravel プロジェクトで Pest をまだ十分に使っていない場合は、Laravel 用プラグインもあわせて確認しておくとスムーズです。
最初に作りたいテスト
最初から複雑な E2E テストを増やすより、まずは主要導線を 1 本ずつ固めるのが実務向きです。
おすすめは次の順番です。
- ログイン
- 一覧表示
- 作成・更新
- 権限による表示分岐
特にログインテストは、フォーム入力、認証、遷移先確認までをまとめて検証できるため、ブラウザテスト導入の入口に向いています。
E2Eテストで見たいポイント
ブラウザテストは、単に「クリックできたか」だけを確認するものではありません。アプリの主要体験が壊れていないかを、利用者目線で押さえるのが目的です。
たとえば次の観点をテストへ落とし込むと効果が出やすくなります。
- ログイン後に正しい画面へ遷移するか
- エラーメッセージが適切に表示されるか
- ボタンやリンクの導線が切れていないか
- 主要フォームが最後まで送信できるか
画面の見た目だけでなく、認証状態やイベント発火など、Laravel 側の検証とあわせて確認できるのが Pest の強みです。
書きすぎないことも大切
E2E テストは強力ですが、なんでもブラウザテストに寄せると、保守コストが上がります。次のように役割分担するとバランスが取りやすくなります。
- 細かい条件分岐はユニットテスト
- API や画面遷移は機能テスト
- 主要な利用導線はブラウザテスト
この分担にすると、テストの実行時間と保守性を両立しやすくなります。
運用で効くポイント
ブラウザテストを継続的に活かすには、失敗したときに調査しやすい状態にしておくことも重要です。
- テスト名を業務フローに沿って書く
- 1本のテストで責務を詰め込みすぎない
- スクリーンショットやログを確認しやすくする
- CI で主要シナリオだけでも継続実行する
導入直後よりも、画面改修やライブラリ更新のあとにこそ、ブラウザテストの価値が出てきます。
まとめ
Pest v4 のブラウザテストは、Laravel アプリの主要導線を実ブラウザで確認したいときに、非常に扱いやすい選択肢です。Laravel 側のテスト資産を活かしながら、画面操作まで含めた品質確認へ広げやすい点が魅力です。
Laravel アプリのテスト戦略や E2E テスト整備をご検討中の方は、ぜひ お問い合わせ ください。