PlaywrightのテストをTestMu AI（LambdaTest）で実行したあと、ダッシュボードでテスト結果を見ると、どれが何のテストなのか判別しづらい状態でした。同じ日に実行したテストが１つの画面に混在して表示されていたり、全てのテストファイル・個々のテストコマンドが１列に繋がって並んでいたり・・・。この記事では、「いつ・どの環境での実行か」「どのテストでエラーが起きているか」がすぐわかるダッシュボードを目指して、表示を整えます。
今回はDeployerの中心目的であるゼロダウンタイムのデプロイについてです。目的はアプリの変更のインストール（コードリリース）をサイトをダウンさせることなく完了させることであり、万が一問題があれば前の変更に１つのコマンドの実行でもとに戻せるという大役のタスクです。
TestMu AI（旧LambdaTest）は、多様なブラウザや実機OS環境をクラウド上で提供するテストプラットフォームです。Playwrightで作成したテストをTestMu AIのクラウドブラウザで実行することで、手元のマシンを使わずにChrome・Firefox・Safari・Edgeなど複数のブラウザでテストを走らせることができます。今回は、すでに構築済みのローカルプロジェクトに対して、クラウドブラウザからテストを実行することを目指します。
deployerの話の続きです。今回はユーザー定義のタスク（レシピとも言う）の話です。タスクはdeployerを使って対象のホストに入って実行できるコマンドです。ちなみに前回のdep run dateのrunはdeployerが定義したタスクです。
同じLaravelのプログラムを複数のサイトにインストールしていると、いちいちそれらのサイトにsshしてプログラムの変更のインストール（デプロイ）が面倒になってきます。こんなときに、とっても助けとなるのがDeployer。今回はそのツールの紹介です。
ローカルの開発環境では、一般的に「開発用DB」と「テスト用DB」を分けて運用します。テストのリセット処理（migrate:freshなど）によって開発中のデータまで消えてしまったり、予期せず書き換わってしまうことがあるからです。Playwrightでも同様に、同じ環境でテストするならDBを分けておくのがベストです。今回は、開発DBとテストDBの切り替え手順について解説します。
Playwrightのページオブジェクトモデル（POM）とは、画面やボタンなどの部品をひとまとめにして管理する仕組みのことです。POMを使うことでテストコードがシンプルになり、またUI変更時にも修正がPOMファイルのみで済むといったメリットがあります。
そしてPOMは、ページ単位だけでなくコンポーネント単位でも導入可能です。この記事では、テストで繰り返し登場する入力項目をPOM化して、再利用できるようにしてゆきます。
ウェブから時間がかかる作業、例えばアップロードした画像の整形などを行うときは、ジョブを作成してキュー使って非同期で実行するのが通常。しかし、Laravel 12.xからジョブをキューを使わずに即バックグラウンドで処理することが可能となりました。今回はその紹介です。
Laravelでは、カスタムに作成したミドルウェアをいろいろな場所で装着することができとてもフレキシブルです。前回ではグローバルやルートで装着しました。今回はLaravel 11.xバージョンから追加されたコントローラでのmiddlewareメソッドで装着してみます。
以前にご紹介したPlaywrightテスト作成の記事では、一連のログイン動作を共通処理として関数化し、使いまわせるようにしました。この方法ではコード上はすっきりしますが、ログイン処理がテストごとに実行される点は同じです。
そこで今回は、PlaywrightのAuthenticationを使って「認証状態」自体を使いまわせるようにしてゆきます。毎回ログイン処理を行う必要がなくなるので、テスト時間の短縮が期待できます。