PlaywrightでE2Eテストを自動化(6)開発DBとテストDBの分離と初期化
ローカルの開発環境では、一般的に「開発用DB」と「テスト用DB」を分けて運用します。テストのリセット処理(migrate:freshなど)によって開発中のデータまで消えてしまったり、予期せず書き換わってしまうことがあるからです。Playwrightでも同様に、同じ環境でテストするならDBを分けておくのがベストです。今回は、開発DBとテストDBの切り替え手順について解説します。
ローカルの開発環境では、一般的に「開発用DB」と「テスト用DB」を分けて運用します。テストのリセット処理(migrate:freshなど)によって開発中のデータまで消えてしまったり、予期せず書き換わってしまうことがあるからです。Playwrightでも同様に、同じ環境でテストするならDBを分けておくのがベストです。今回は、開発DBとテストDBの切り替え手順について解説します。
Playwrightのページオブジェクトモデル(POM)とは、画面やボタンなどの部品をひとまとめにして管理する仕組みのことです。POMを使うことでテストコードがシンプルになり、またUI変更時にも修正がPOMファイルのみで済むといったメリットがあります。 そしてPOMは、ページ単位だけでなくコンポーネント単位でも導入可能です。この記事では、テストで繰り返し登場する入力項目をPOM化して、再利用できるようにしてゆきます。
以前にご紹介したPlaywrightテスト作成の記事では、一連のログイン動作を共通処理として関数化し、使いまわせるようにしました。この方法ではコード上はすっきりしますが、ログイン処理がテストごとに実行される点は同じです。 そこで今回は、PlaywrightのAuthenticationを使って「認証状態」自体を使いまわせるようにしてゆきます。毎回ログイン処理を行う必要がなくなるので、テスト時間の短縮が期待できます。
Pest4からブラウザテスト機能が追加され、簡単なセットアップだけでPlaywrightを使ったE2Eテストが使えるようになりました。今回はLaravelで作成したプロジェクトを使って、セットアップからテストコード作成までの流れを実際に試してみます。
Playwrightから新しくAgents機能がリリースされました。テストプランの作成・テストコードの作成・エラーとなったテストの修正を行なう、3つのエージェント機能を備えています。今回は、Claude CodeとAgentsを使ってLaravelプロジェクトにE2Eテストを追加してみます。
Playwright、3記事目の今回はcodegenを使ってテストコードを生成します。codegenは、ブラウザ上での実際の操作を記録し、それをPlaywrightのテストコードに変換してくれる便利な機能です。VSCodeの拡張機能「Playwright Test for VSCode」も存在していますが、今回はシンプルにPlaywrightの機能のみを使用して作成します。
前回の記事で、Playwrightのインストールと動作確認までを行いました。さっそくテストコードの自動生成機能を使って簡単にテストを作成したいところですが、現時点ではまだ生成されたコードをそのまま使うというよりも、人間が確認・修正する場合も多いと思います。 そこで今回は、シンプルなログイン・ログアウトのテストを使ってPlaywrightの基本的なテストの書き方をご紹介します。
FormRequestのユニットテスト2記事目の今回は、prepareForValidation()を含めてテストをしたい場合はどうするのか?についてご紹介します。前回に続いて、「店舗情報更新画面」のバリデーション・認可処理を行うShopUpdateRequestを例にテストを作成します。
Laravel12.xでFormRequestのユニットテストを作成します。今回の記事では基本的なテストから、少しややこしい$this->route()のようなルートパラメータを取得する必要がある場合の書き方などをご紹介します。
テストを書くとき、テストパターンや入力値の組み合わせが増え、データの管理が煩雑になりがちです。Pestではwith()やdataset()を使って基本的なデータ整理ができますが、後から読んでも理解しやすい・修正しやすいコードを目指して、Combining DatasetsやSharing Datasetsを活用し、テストコードを整理してみます。