Laravel on ララジャパン

ローカル開発環境のPlaywrightテストをTestMu AI（LambdaTest）で実行

Fri, 24 Apr 2026 00:21:04 +0900

TestMu AI（旧LambdaTest）は、多様なブラウザや実機OS環境をクラウド上で提供するテストプラットフォームです。Playwrightで作成したテストをTestMu AIのクラウドブラウザで実行することで、手元のマシンを使わずにChrome・Firefox・Safari・Edgeなど複数のブラウザでテストを走らせることができます。今回は、すでに構築済みのローカルプロジェクトに対して、クラウドブラウザからテストを実行することを目指します。

通常のPlaywrightテストもすでに構築済みの状態からTestMu AIの導入を進めますので、まだPlaywrightの環境を構築していない方はこちらもご参照ください。

PlaywrightでE2Eテストを自動化（１）セットアップ PlaywrightでE2Eテストを自動化（２）ログイン・ログアウト

本記事のゴール：公開サイトからローカル環境のテストまで

「ローカルのプロジェクトに対してクラウドブラウザからテスト実行」を実現するにあたり、この記事では２段階で環境構築を進めてゆきます。まずは公開されているURL（デモサイト）をテスト対象に設定を進め、TestMu AIとPlaywrightとの接続を確認します。

そこまでできたら次に、ローカルの開発サーバーをテスト対象に変更します。その際、クラウドブラウザからローカルサーバーへ接続するために、TestMu AIが提供しているTunnelという機能を使います。

なお、サービス名は現在TestMu AIに変更されていますが、今回使用するnpmパッケージ（@lambdatest/node-tunnel）やAPIのエンドポイント（cdp.lambdatest.com）など関連するコードは引き続きLambdaTestの名称が使われています。そのため本記事内でも以降はLambdaTestの表記で統一します。

LambdaTestの接続情報を取得

クラウドでの自動テストには、LambdaTestのWeb Automationという機能を使う必要があります。無料会員でも100分まではこの機能を使うことができますので、お試しにはぴったりです。

こちらから会員登録し、こちらにアクセスするとAutomationに必要な接続情報が取得できます。

取得した接続情報を.env.playwrightに追記します。

.env.playwright

LT_USERNAME=ユーザー名
LT_ACCESS_KEY=アクセスキー

デモサイトへアクセスするテスト

必要な情報が揃ったので、次はPlaywrightとLambdaTestの接続設定を進めます。

冒頭でお伝えしたように、まずは公開されているデモサイトをテスト対象とします。テストもシンプルにデモサイトにアクセスするだけの以下のような内容で、PlaywrightからLambdaTestのクラウドブラウザに接続し、動作を確認します。

e2e/lambdatest-demo.spec.ts

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

test('トップページが表示される', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveTitle(/Your Store/i);
});

公開ページにアクセスするための設定ファイル

次にconfigファイルを作成します。既存のplaywright.config.tsはローカルでテストを実行する際の設定ファイルとして変更せず、新たにplaywright.lambdatest.config.tsを作成して、こちらをLambdaTest用の設定ファイルとします。

まずはコードの全体をお見せします。

playwright.lambdatest.config.ts

import { defineConfig, devices } from '@playwright/test';
import dotenv from 'dotenv';
import { fileURLToPath } from 'url';
import path from 'path';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

dotenv.config({ path: path.resolve(__dirname, '.env') });
dotenv.config({ path: path.resolve(__dirname, '.env.playwright'), override: true });

const LT_USERNAME = process.env.LT_USERNAME ?? '';
const LT_ACCESS_KEY = process.env.LT_ACCESS_KEY ?? '';

// ---- デバイスマッピング ----
// DEVICE 変数1つで「LTブラウザ名・デフォルトOS・Playwrightデバイス」が連動して決まる。
type DeviceConfig = {
  ltBrowser: string;
  browserVersion: string;
  platform: string;
  device: string;
};

const DEVICE_MAP: Record<string, DeviceConfig> = {
  chrome: { ltBrowser: 'Chrome', browserVersion: 'latest', platform: 'Windows 11', device: 'Desktop Chrome' },
  firefox: { ltBrowser: 'pw-firefox', browserVersion: 'latest', platform: 'Windows 11', device: 'Desktop Firefox' },
  edge: { ltBrowser: 'Microsoft Edge', browserVersion: 'latest', platform: 'Windows 11', device: 'Desktop Edge' },
  safari: { ltBrowser: 'pw-webkit', browserVersion: 'latest', platform: 'MacOS Tahoe', device: 'Desktop Safari' },
  ios: { ltBrowser: 'pw-webkit', browserVersion: 'latest', platform: 'MacOS Tahoe', device: 'iPhone 15' },
};

const deviceKey = process.env.DEVICE ?? 'chrome';

if (!(deviceKey in DEVICE_MAP)) {
  console.error(`エラー: DEVICE="${deviceKey}" は未定義です。有効な値: ${Object.keys(DEVICE_MAP).join(', ')}`);
  process.exit(1);
}

const { ltBrowser, browserVersion, platform: defaultPlatform, device: deviceName } = DEVICE_MAP[deviceKey];
const ltPlatform = process.env.LT_PLATFORM ?? defaultPlatform;
const selectedDevice = devices[deviceName];

// ---- LambdaTest CDP エンドポイント ----
function ltEndpoint(testName: string) {
  return `wss://cdp.lambdatest.com/playwright?capabilities=${encodeURIComponent(
    JSON.stringify({
      browserName: ltBrowser,
      browserVersion,
      'LT:Options': {
        user: LT_USERNAME,
        accessKey: LT_ACCESS_KEY,
        build: 'Playwright Demo',
        name: `${testName} [${deviceKey} / ${ltPlatform}]`,
        platform: ltPlatform,
        tunnel: false,
        network: true,
        console: true,
        video: true,
      },
    })
  )}`;
}

// ---- Playwright 設定 ----
export default defineConfig({
  testDir: './e2e',
  fullyParallel: false,
  workers: 1,
  timeout: 60_000,

  reporter: [['html'], ['list']],

  use: {
    baseURL: 'https://ecommerce-playground.lambdatest.io',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },

  projects: [
    {
      name: `${deviceKey}`,
      testMatch: '**/lambdatest-demo.spec.ts',
      use: {
        ...selectedDevice,
        connectOptions: { wsEndpoint: ltEndpoint(deviceKey) },
      },
    },
  ],
});

大きく分けて ①環境変数の読み込み、②デバイスマッピング、③LambdaTestへの接続設定、④Playwrightの実行設定、の4つのブロックで構成されており、ポイントは以下になります。

②デバイスマッピング

DEVICE_MAPでは、ブラウザとOSの組み合わせを定義しています。

テスト実行時にDEVICE=safariのように環境変数を渡すと、マップのsafari: { ltBrowser: ‘pw-webkit’, browserVersion: ‘26.0’, platform: ‘MacOS Tahoe’, device: ‘Desktop Safari’ }に合致してltBrowser（LambdaTestに渡すブラウザ名）・platform（OS）・deviceの3つが同時に確定します。

この設定のおかげで、「Windows上のSafari」という存在しない組み合わせを指定することを防げます。

OSとブラウザの組み合わせについては少しややこしいので、公式ドキュメントやジェネレーターを使って確認することをおすすめします。

公式ドキュメントジェネレーター

③LambdaTestへの接続設定

ltEndpoint()では、使用するブラウザ・バージョン・OS・認証情報など渡し、LambdaTestのクラウドブラウザに接続するためのURLを生成します。このURLを後述のconnectOptionsに渡すことで、PlaywrightがLambdaTestのクラウドブラウザに接続できるようになります。

④Playwrightの実行設定

Playwrightの設定はローカルで動かす時と似ていますが、以下の違いがあります。

・・・・・
// ---- Playwright 設定 ----
export default defineConfig({
・・・・・
  use: {
    baseURL: 'https://ecommerce-playground.lambdatest.io',
・・・・・
  projects: [
    {
      name: `${deviceKey}`,
      testMatch: '**/lambdatest-demo.spec.ts',
      use: {
        ...selectedDevice,
        connectOptions: { wsEndpoint: ltEndpoint(deviceKey) },
      },
    },

baseURLには、第１段階なのでデモサイトを対象としています。

そしてprojectsのconnectOptionsの箇所は、「ローカルのブラウザを起動する代わりにリモートのブラウザに接続する」ための設定です。ここで渡しているのが③で生成したクラウド接続用のURLになっています。

デモサイトへのテスト実行

ここでいったん動作確認のため、以下のコマンドでテストを実行してみます。環境変数にブラウザ名を渡していないので、デフォルトのchromeで実行されるはずです。

$ npx playwright test --config=playwright.lambdatest.config.ts

テスト実行中、ブラウザでLambdaTestのAutomationダッシュボードへアクセスするとリアルタイムでテストが実行されてデモサイトにアクセスしている様子が確認できます。ちゃんとchromeで実行されていますね。

無事に動作確認ができたので、次はテスト対象をデモサイトからローカルサーバーに切り替えます。

Tunnelバイナリ管理のライブラリ

ローカルサーバー（http://127.0.0.1:8001）をテストするにあたり、クラウドブラウザからlocalhostへは接続できないためTunnel（トンネル）という機能を使う必要があります。

今回は公式が提供しているNode.jsライブラリを使ってトンネル管理を行います。トンネルを動かすためのバイナリファイルを自動でダウンロードし、そのバイナリをNode.jsのコードから起動・停止できるようにしてくれるパッケージです。

以下のコマンドでインストールします。

$ npm install -D @lambdatest/node-tunnel

また、このライブラリを使用すると.lambdatestというディレクトリに自動的にバイナリファイルがダウンロードされるため、.gitignoreへ追記が必要です。実行時にはログファイルも出るため、こちらも併せて記載します。

.gitignore

・・・・・
*.log
.lambdatest/

Tunnel実行ファイル

先ほどインストールしたライブラリを使ったトンネルの起動・停止をPlaywrightに組み込むため、以下の実行ファイルを作成します。トンネル起動用・終了用の２ファイルあります。

トンネル起動用

e2e/support/lambdatest-tunnel.ts

import tunnel from '@lambdatest/node-tunnel';
import dotenv from 'dotenv';
import { fileURLToPath } from 'url';
import path from 'path';

const __dirname = path.dirname(fileURLToPath(import.meta.url));
dotenv.config({ path: path.resolve(__dirname, '..', '..', '.env') });
dotenv.config({ path: path.resolve(__dirname, '..', '..', '.env.playwright'), override: true });

const LT_USERNAME   = process.env.LT_USERNAME   ?? '';
const LT_ACCESS_KEY = process.env.LT_ACCESS_KEY ?? '';

export default async function setup() {
  if (!LT_USERNAME || !LT_ACCESS_KEY) {
    throw new Error('LT_USERNAME と LT_ACCESS_KEY を .env.playwright に設定してください。');
  }

  console.log('[LambdaTest] トンネルを起動中...');
  const t = new tunnel();

  await new Promise<void>((resolve, reject) => {
    t.start(
      { user: LT_USERNAME, key: LT_ACCESS_KEY },
      (err: Error | null) => {
        if (err) reject(err);
        else {
          console.log('[LambdaTest] トンネル起動完了');
          resolve();
        }
      }
    );
  });

  (globalThis as any).__lt_tunnel__ = t;
}

トンネル停止用

e2e/support/lambdatest-tunnel-teardown.ts

export default async function teardown() {
  const t = (globalThis as any).__lt_tunnel__;
  if (t) {
    console.log('[LambdaTest] トンネルを停止中...');
    await new Promise<void>((resolve) => t.stop(resolve));
    console.log('[LambdaTest] トンネル停止完了');
  }
}

このファイルを後述のplaywright.lambdatest.config.tsのglobalSetupとglobalTeardownに指定することで、テスト実行のたびに手動でトンネルを起動する手間がなくなります。

playwright.lambdatest.config.tsを更新

playwright.lambdatest.config.tsを、トンネルを使ったバージョンに更新します。以下、更新箇所を抜粋しています。

・・・・・
// ---- LambdaTest CDP エンドポイント ----
function ltEndpoint(testName: string) {
  return `wss://cdp.lambdatest.com/playwright?capabilities=${encodeURIComponent(
    JSON.stringify({
・・・・・
      'LT:Options': {
・・・・・
        tunnel: true, // トンネルをtrueに
・・・・・
      },
    })
  )}`;

// ---- Playwright 設定 ----
export default defineConfig({
・・・・・
  globalSetup:    './e2e/support/lambdatest-tunnel.ts',          // トンネル起動
  globalTeardown: './e2e/support/lambdatest-tunnel-teardown.ts', // トンネル停止

  use: {
    baseURL: 'http://127.0.0.1:8001', // デモサイトのURLからローカルへ変更
・・・・・
  },

  projects: [
    // DB リセット＆シード（ローカル実行）
    { name: 'db-setup', testMatch: '**/db.setup.ts' },

    // 実行したいテスト
    {
      name: `${deviceKey} 未ログイン`,
      testMatch: '**/auth.spec.ts',
      use: {
        ...selectedDevice,
        connectOptions: { wsEndpoint: ltEndpoint(`${deviceKey} 未ログイン`) },
      },
      dependencies: ['db-setup'],
    },
  ],

  webServer: {
    command: 'php artisan serve --port=8001',
    url: 'http://127.0.0.1:8001',
    reuseExistingServer: true,
    stdout: 'ignore',
    stderr: 'pipe',
  },
});

重要な変更箇所は以下の４点です。

トンネル設定：ltEndpoint()でtunnel: trueとし、トンネルを使う旨を設定します。
globalSetup / globalTeardown：先ほど作成したトンネル実行ファイルを指定します。これによりテスト実行前にトンネルが自動で起動し、終了後に停止します。
baseURL：デモサイトのURLからローカルサーバーのURLに変更します。
projects：テストで実行したいprojectを並べる点は通常のPlaywrightの記述と同じですが、DB初期化はローカルで行い、テスト本体のみクラウドブラウザで実行する構成となっています。この棲み分けはconnectOptionsの指定あり・なしによって決まり、connectOptionsが指定されているprojectはLambdaTestのクラウドブラウザで実行され、指定されていないprojectはローカルのブラウザで実行されます。

テスト実行

トンネルの設定も完了したので、改めてテストを実行してみます。

$ npx playwright test --config=playwright.lambdatest.config.ts
◇ injected env (44) from .env // tip: ◈ encrypted .env [www.dotenvx.com]
◇ injected env (5) from .env.playwright // tip: ◈ encrypted .env [www.dotenvx.com]
◇ injected env (0) from .env // tip: ⌘ enable debugging { debug: true }
◇ injected env (5) from .env.playwright // tip: ⌘ suppress logs { quiet: true }
[LambdaTest] トンネルを起動中...
Current version of Node Tunnel:  4.0.11
Verifying credentials
Auth succeeded
Checking for updates
Binary already at latest version
Starting tunnel
Tunnel successfully initiated. You can start testing now
[LambdaTest] トンネル起動完了

Running 4 tests using 1 worker

◇ injected env (0) from .env // tip: ⌘ enable debugging { debug: true }
◇ injected env (5) from .env.playwright // tip: ◈ encrypted .env [www.dotenvx.com]
     1 [db-setup] › e2e/support/db.setup.ts:5:1 › reset database

・・・・・中略・・・・・

  ✓  2 [chrome 未ログイン] › e2e/auth.spec.ts:4:3 › 認証機能 › ログインページが表示される (5.6s)
[LambdaTest] トンネルを停止中...
[LambdaTest] トンネル停止完了

  4 passed (1.3m)

テストの前後でトンネルが問題なく起動・終了しているようです。クラウドのダッシュボードでも実行中の動作が確認でき、トンネル経由でローカルサーバーへのテストが成功しました！

safari/ios対応

ここまでの設定でchrome・edgeの実行は問題なかったのですが、safari・iosで以下のようなエラーが発生しました。

Error: page.goto: Could not connect to the server.

ログを確認すると、トンネル接続自体は成功しているものの、LambdaTest側のWebKit（Safari）ブラウザがローカルのbaseURLに接続できずに失敗していることがわかりました。

これはWebKit特有の仕様が原因だそうです。LambdaTestの公式ドキュメントでもlocalhostの代わりにlocalhost.lambdatest.comを使うよう案内されており、baseURLを以下のように変更することで解決しました。

playwright.lambdatest.config.ts

  // Before
  use: {
    baseURL: 'http://127.0.0.1:8001',
・・・・・
  },

  // After
  use: {
    baseURL: 'http://localhost.lambdatest.com:8001',
・・・・・
  },

公式ドキュメント

この修正で、safariやiosでもトンネルを使ったクラウドテストが実行できるようになりました。ですがsafariやiosは接続が少し重く、同じクラウド実行でもchromeなどに比べて1.5倍〜時間がかかる感じがします。

deployerで複数サイトを管理（２）タスクを定義

Wed, 15 Apr 2026 11:07:41 +0900

deployerの話の続きです。今回はユーザー定義のタスク（レシピとも言う）の話です。タスクはdeployerを使って対象のホストに入って実行できるコマンドです。ちなみに前回のdep run dateのrunはdeployerが定義したタスクです。

Laravelアプリをダウンさせるタスクを定義

このブログの読者はもちろんLaravelユーザーなので、そのアプリのダウンのコマンドをdeployerのタスクの例として定義します。

deploy.php

namespace Deployer;

import('hosts.yml');

desc('メンテナンスモードにする');
task('app:down', function () {
    cd('{{deploy_path}}');
    $secret = run('echo $RANDOM | md5sum | head -c 10'); // ランダムなキーを生成
    $result = run("php artisan down --secret=$secret");
    writeln($result);
});

上において、cd(’{{deploy_path}}’)は、hosts.ymlで定義したホストにおいてLaravelのアプリが存在するパス名です。つまり、まずそこへcdしてからphp artisan downを実行ということです。

前回定義した、hosts.ymlは以下です。

hosts.yml

hosts:
  production:
    hostname: www.larajapan.com
    remote_user: deployer
    deploy_path: ~/example

  staging:
    hostname: staging.larajapan.com
    remote_user: deployer
    deploy_path: ~/example

さきのタスクを実行すると、

$ dep app:down

Select hosts: (comma separated)
  [0] staging
  [1] production
 > 0
task app:down
[staging]
   INFO  Application is now in maintenance mode.

   INFO  You may bypass maintenance mode via [http://staging.larajapan.com/040538d125].

ここで大事なのは、上のphp artisan down –secret=の実行は、そこで与えられたシークレットキーを知るユーザーのみダウンしていない状態でLaravelのアプリへのアクセスを許します。今回のようにランダムな覚えにくいシークレットキーを生成すると、それをいちいちタイプするのは面倒ですよね。しかし、Laravelのdownコマンドは実行後にそのリンクを親切に出力してくれます。そのために、先のタスクの定義において、writeln($result)として画面に出力するのが重要となります。

タスクを強化

app:downのタスクは先に見せたように、ローカルから対象のマシンにsshを手動で実行することなく簡単にリモートで操作できてしまいます。その便利さは時には過ち実行も起きやすいということです。実行する前に確認のプロンプトも追加しましょう。 deployerでは、確認のプロンプトはaskConfirmation()の関数が使えます。

...
desc('メンテナンスモードにする');
task('app:down', function () {

   // 以下が追加した部分です。
    $host = currentHost()->getAlias();
    if (! askConfirmation("<comment>$host</comment>のホストをメンテナンスモードにしますか？", false)) {
        writeln('<error>実行はキャンセルされました.</error>');
        exit(1);
    }

    cd('{{deploy_path}}');
    $secret = run('echo $RANDOM | md5sum | head -c 10'); // ランダムなキーを生成
    $result = run("php artisan down --secret=$secret");
    writeln($result);
});

実行してみましょう。

Select hosts: (comma separated)
  [0] staging
  [1] production
 > 0
task app:down
[staging] stagingのホストをメンテナンスモードにしますか？ [y/N] n
[staging] 実行はキャンセルされました.
ERROR: Task app:down failed!

上では、小文字のnをタイプすることで実行をキャンセルできます。もちろん大文字のNでも同じです。ちなみに、[y/N]とNが大文字表示されているのは、デフォルトがNoということで、単にnやNをタイプせずにリターンキーを押すことでもキャンセルとなります。

確認のプロンプトを入れることで過ちの防止となりましたが、確認の上で実行としたときに、実行後に本当にアプリがダウンとなったか確かめたいですね。それは、php artisan aboutに表示されるMaintenance Modeの行を見ることで確認できます。

desc('メンテナンスモードにする');
task('app:down', function () {
    $host = currentHost()->getAlias();
    if (! askConfirmation("<comment>$host</comment>のホストをメンテナンスモードにしますか？", false)) {
        writeln('<error>実行はキャンセルされました.</error>');
        exit(1);
    }

    cd('{{deploy_path}}');
    $secret = run('echo $RANDOM | md5sum | head -c 10');
    $result = run("php artisan down --secret=$secret");
    writeln($result);

    //　以下でダウンされていか確認
    $result = run('php artisan about | grep -i maintenance');
    writeln($result);
});

実行してみましょう。

Select hosts: (comma separated)
  [0] staging
  [1] production
 > 0
task app:down
[staging] stagingのホストをメンテナンスモードにしますか？ [y/N] y
[staging]
   INFO  Application is now in maintenance mode.

   INFO  You may bypass maintenance mode via [http://localhost/3d895d8b57].
[staging]   Maintenance Mode ................................................... ENABLED

ENABLEDはメンテナンスモードとなって落ちているということで、実行は成功です。OFFと表示されていればダウンとならなかったということで異常が起こったということです。

deployerで複数サイトを管理（１）

Sat, 28 Mar 2026 07:19:49 +0900

同じLaravelのプログラムを複数のサイトにインストールしていると、いちいちそれらのサイトにsshしてプログラムの変更のインストール（デプロイ）が面倒になってきます。こんなときに、とっても助けとなるのがDeployer。今回はそのツールの紹介です。

Deployerのインストール

まず、Laravelのプロジェクトにdeployerをインストール。

$ composer require deployer/deployer --dev

インストール後に、vendor/bin/depが作成されます。このコマンドは頻繁に使用されるので、bashの初期設定のファイルに~/.bashrcに以下のようにエイリアスを入れて、

.bashrc

...
alias dep='vendor/bin/dep'
...

以下を実行します。

. ~/.bashrc

これで、コマンドラインでdepだけで実行できます。

Deployerの初期化

Deployerは、先のdepのコマンドを使用してタスクを実行するために、プロジェクトのルートディレクトリにdeployer.phpのファイルが必要です。そのファイルの作成には以下を実行します。

$ dep init

以下のように選択肢が表示され順に答えていきます。最後のHosts以外はデフォルト（括弧の中に表示されている）を選択しています。

Select recipe language [php]:
  [0] php
  [1] yaml
 > 

 Select project template [common]:
  [0 ] cakephp
  [1 ] codeigniter
  [2 ] codeigniter4
  [3 ] common
  [4 ] composer
  [5 ] contao
  [6 ] craftcms
  [7 ] drupal7
  [8 ] drupal8
  [9 ] flow_framework
  [10] fuelphp
  [11] joomla
  [12] laravel
  [13] magento
  [14] magento2
  [15] pimcore
  [16] prestashop
  [17] provision
  [18] shopware
  [19] silverstripe
  [20] spiral
  [21] statamic
  [22] sulu
  [23] symfony
  [24] typo3
  [25] wordpress
  [26] yii
  [27] zend_framework
 > 

 Repository [git@github.com:larajapan/example.git]:
 >

 Project name [example]:
 >

 Hosts (comma separated) []:
 > www.larajapan.com,staging.larajapan.com

Successfully created deploy.php

作成されたdeployer.phpは、

deployer.php

namespace Deployer;

require 'recipe/common.php';

// Config

set('repository', 'git@github.com:larajapan/example.git');

add('shared_files', []);
add('shared_dirs', []);
add('writable_dirs', []);

// Hosts

host('www.larajapan.com')
    ->set('remote_user', 'deployer')
    ->set('deploy_path', '~/example');
host('staging.larajapan.com')
    ->set('remote_user', 'deployer')
    ->set('deploy_path', '~/example');

// Hooks

after('deploy:failed', 'deploy:unlock');

上での設定は、・ depでsshでdeployerのユーザーとしてアクセス可能なホストが２つある。www.larajapan.comとstaging.larajapan.com ・どちらのホストもLaravelのアプリは、~/exampleのディレクトリにあるです。

deployer.phpは、もちろん手動で編集可能なので上の設定ではいくらでも変更が可能です。

複数のサイトにいっぺんにアクセス

準備ができたところ、早速以下を実行してみてください。

$ dep run date

ホストの選択肢が表示されます。１番目つまり0を選択するとそのホストへsshしてdateコマンドを実行します。

Select hosts: (comma separated)
  [0] www.larajapan.com
  [1] staging.larajapan.com
 > 0
[www.larajapan.com] Thu Mar 26 08:07:54 JST 2026

選択が面倒なら、コマンドラインでもホストを指定できます。

$ dep run date www.larajapan.com

さらに、長いホスト名のタイプが面倒なら、deployer.phpを編集して、ホストのエイリアスを指定できます。

// Hosts

host('production')
    ->setHostname('www.larajapan.com')
    ->set('remote_user', 'deployer')
    ->set('deploy_path', '~/example');
host('staging')
    ->setHostname('staging.larajapan.com')
    ->set('remote_user', 'deployer')
    ->set('deploy_path', '~/example');

とすれば、

$ dep run date production

と実行できます。

最後に、定義されている全部のサイトで実行したいなら、allを渡します。

$ dep run date all
[production] Thu Mar 26 08:12:02 JST 2026
[live] Thu Mar 26 08:12:04 JST 2026

便利ですね。

ホスト情報をYAMLファイルにする

ホストが２つくらいなら、deploy.php内でのホストの定義で十分ですが、これが10個もなると読みづらくなります。そのような場合は、ホストの定義をYAMLのファイルに抽出して分けることが可能です。

hosts.yml

hosts:
  production:
    hostname: www.larajapan.com
    remote_user: deployer
    deploy_path: ~/example

  staging:
    hostname: staging.larajapan.com
    remote_user: deployer
    deploy_path: ~/example

定義があった元の部分では、以下のようにimportに置き換えます。

deploy.php

// Hosts

import('hosts.yml');

整理されてすっきりしました。

PlaywrightでE2Eテストを自動化（６）開発DBとテストDBの分離と初期化

Tue, 24 Mar 2026 11:54:39 +0900

ローカルの開発環境では、一般的に「開発用DB」と「テスト用DB」を分けて運用します。テストのリセット処理（migrate:freshなど）によって開発中のデータまで消えてしまったり、予期せず書き換わってしまうことがあるからです。Playwrightでも同様に、同じ環境でテストするならDBを分けておくのがベストです。今回は、開発DBとテストDBの切り替え手順について解説します。

プロジェクトの構成

今回の記事で扱うPlaywrightは、Laravelプロジェクトの中にe2eディレクトリとして存在しており、以下のような構成になっています。

laravel-project/ ├── app/ ├── … └── e2e/（Playwright）

そして今回はDBだけではなく、それぞれの環境が干渉しないようサーバのポートも以下のように使い分けることにします。

ローカルの開発環境：8000 Playwrightの実行環境：8001

ではここから設定を進めていきます。順を追って進めるためconfigファイルが複数回に分けて登場しますが、最後にconfigの全体もご紹介します。

.env.playwright

まずは.env.playwrightを作成します。以下のように最小限に内容のみ記載します。

.env.playwright

APP_ENV=playwright
DB_DATABASE=database/playwright.sqlite

APP_ENVは今回の設定上必須ではありませんが、Laravelの動作中localと認識されないように環境をplaywrightと明示しておきます。そしてplaywright用のDBとして、今回はsqliteを使用します。

gitignoreに追加することもお忘れなく。

.gitignore

・・・・・
.env.playwright

.env.playwrightをconfigファイルに追加

次に、作成した.env.playwrightをplaywright.config.tsに追加します。（TypeScriptの記述となっています）

playwright.config.ts

import { defineConfig, devices } from '@playwright/test';
import dotenv from 'dotenv';
import { fileURLToPath } from 'url';
import path from 'path';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

// .env を読み込んだあと、.env.playwright で差分を上書き
dotenv.config({ path: path.resolve(__dirname, '.env') });
dotenv.config({ path: path.resolve(__dirname, '.env.playwright'), override: true });
・・・・・

dotenv.config()を使用して.envと.env.playwrightの両方を読み込んでいます。その際.env → .env.playwrightの順で読み込み、後者で上書きする形としています。そうすることで.env.playwrightの記述は最低限の変更箇所のみで済みます。

環境にdotenvがインストールされていない場合はテスト実行時にコケてしまうので、以下のコマンドでインストールしておいてくださいね。

$ npm install dotenv

Playwright用のSeeder

次にSeederを作成します。Laravelプロジェクトならすでに存在しているであろうDatabaseSeederはユニットテストで使用するため、Playwright専用のSeederを作成することにします。

database/seeders/PlaywrightSeeder.php

namespace Database\Seeders;

use App\Models\User;
use Illuminate\Database\Seeder;

class PlaywrightSeeder extends Seeder
{
    public function run(): void
    {
        $user = User::factory()->create([
            'name'  => 'Test User',
            'email' => 'test@example.com',
        ]);

        $this->callWith(FavoriteFoodSeeder::class, ['user' => $user]);
        $this->callWith(MealSeeder::class, ['user' => $user]);
    }
}

ユーザーと、ユーザーに紐づく食事データなどの基本情報を作成するシンプルな内容となっています。

Seeder実行ファイルの作成と設定

次に、作成したSeederを実行するためのセットアップファイルを作成します。ファイル名はなんでも良いですが、今回はdb.setup.tsとしました。

e2e/db.setup.ts

import { test as setup } from '@playwright/test';
import { execSync } from 'child_process';
import { existsSync, writeFileSync } from 'fs';

setup('reset database', async () => {
  // SQLiteファイルが存在しない場合は作成する
  if (!existsSync('database/playwright.sqlite')) {
    writeFileSync('database/playwright.sqlite', '');
  }

  execSync('php artisan migrate:fresh --seeder=PlaywrightSeeder', { stdio: 'inherit' });
});

setup()を使用して、その中に実行内容を定義します。第１引数に指定している文字列はテスト実行後のHTMLレポートに表示されるので、何をしているのかわかるような内容にしたほうが良いです。

そしてexecSync()を使ってartisanコマンドを実行します。先ほどconfigファイルで設定した.env.playwrightの情報を元に実行されますので、マイグレーションはテスト用DBであるdatabase/playwright.sqliteに対して行われます。

また{ stdio: ‘inherit’ }を指定することで、マイグレーション実行時の進捗状況や、成功・エラーメッセージがターミナルに表示されるようになります。

DBセットアップファイルをconfigファイルで読み込む

再びplaywright.config.tsに戻ります。先ほど作成したdb.setup.tsをconfigファイルのprojectsに追加します。

少しわかりにくいので、追加前の該当部分を先にお見せします。もともとは以下のように「setup（認証情報のセットアップ）」と、「chromium（ブラウザテスト）」の２つのプロジェクトがありました。

db-setup追加前のplaywright.config.ts

・・・・・
  projects: [
    // Setup project for authentication
    { name: 'setup', testMatch: '**/auth.setup.ts' },

    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        // Use prepared auth state.
        storageState: 'playwright/.auth/user.json',
      },
      dependencies: ['setup'],
    },
  ],
・・・・・

ここにDBのセットアッププロジェクトを追加すると、以下のようになります。

db-setup追加後のplaywright.config.ts

・・・・・
  projects: [
    // DB reset and seeding
    { name: 'db-setup', testMatch: '**/db.setup.ts' },  // ここを追加

    // Setup project for authentication
    { name: 'setup', testMatch: '**/auth.setup.ts', dependencies: ['db-setup'] },  // ここを追加

    {
      name: 'chromium', // ここは変更なし
      use: {
        ...devices['Desktop Chrome'],
        // Use prepared auth state.
        storageState: 'playwright/.auth/user.json',
      },
      dependencies: ['setup'],
    },
  ],
・・・・・

追加したのは{ name: ‘db-setup’, testMatch: ‘**/db.setup.ts’ },の行と、setupプロジェクトへの依存関係dependencies: [‘db-setup’] の部分です。

元からあったchromiumプロジェクトにも依存関係dependencies: [‘setup’]がありますので、今回の変更により、テスト開始時の実行順序は以下のようになります。

db-setup：まずDBをリセットしてデータを投入する
setup：DBの準備が整ったあとで、ログイン認証を行い状態を保存する
chromium：全ての準備（DBと認証）が終わったあとで、実際のテストを開始する

webServerの設定

最後は、テスト用サーバを起動するための設定です。

Playwrightには、テスト開始時に自動でローカルサーバを立ち上げてくれるwebServerという機能があります。これを利用して、開発用の8000番とは異なるテスト専用ポートの8001番でアプリを起動するようconfigファイルを編集します。

playwright.config.ts

・・・・・
export default defineConfig({
  use: {
    /* Base URL to use in actions like `await page.goto('/')`. */
    baseURL: 'http://127.0.0.1:8001',
・・・・・
  },
  webServer: {
    command: 'php artisan serve --port=8001',
    url: 'http://127.0.0.1:8001',
    reuseExistingServer: !process.env.CI,
    stdout: 'ignore',
    stderr: 'pipe',
  },
});

useセクションのbaseURLを、ポート8000から8001に変更。そしてwebServerセクションを新規に追加しました。webServerでは以下のような項目を設定しています。

command：テスト開始前に実行するシェルコマンドを指定
url：サーバーの起動完了を判定するためのURL（このURLにアクセス可能になるまでテストを待機）
reuseExistingServer：すでにサーバーが起動している場合の挙動を制御（!process.env.CIとすることで、ローカルなどCI以外の環境の場合、既存サーバーがあれば再利用、無ければ起動する、という動作になる）
stdout：通常ログの出力設定（ignoreを指定すると、正常時のログは表示しない）
stderr：エラーログの出力設定（pipeを指定すると、起動失敗やエラー時のみターミナルに表示）

このようにwebServerを設定しておくことで、テスト用サーバーを手動でオン・オフにする必要がなく、またテスト中に意図しない開発用DBに接続してしまう危険を回避できます。

これでテスト環境とのDB分離・リセットの設定が完了しました！

最終的なplaywright.config.ts

ここまでの設定を反映した、最終的なplaywright.config.tsは以下のようになります。

playwright.config.ts

import { defineConfig, devices } from '@playwright/test';
import dotenv from 'dotenv';
import { fileURLToPath } from 'url';
import path from 'path';

const __dirname = path.dirname(fileURLToPath(import.meta.url));

// .env を読み込んだあと、.env.playwright で差分を上書き
dotenv.config({ path: path.resolve(__dirname, '.env') });
dotenv.config({ path: path.resolve(__dirname, '.env.playwright'), override: true });

/**
 * Playwright E2E Test Configuration
 * @see https://playwright.dev/docs/test-configuration
 */
export default defineConfig({
  testDir: './e2e',

  /* Run tests in files in parallel */
  fullyParallel: false,

  /* Fail the build on CI if you accidentally left test.only in the source code. */
  forbidOnly: !!process.env.CI,

  /* Retry on CI only */
  retries: process.env.CI ? 2 : 0,

  /* Opt out of parallel tests on CI. */
  // workers: process.env.CI ? 1 : undefined,
  workers: 1,

  /* Reporter to use. See https://playwright.dev/docs/test-reporters */
  reporter: 'html',

  /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
  use: {
    /* Base URL to use in actions like `await page.goto('/')`. */
    baseURL: 'http://127.0.0.1:8001',

    /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
    trace: 'on-first-retry',

    /* Screenshot on failure */
    screenshot: 'only-on-failure',

    /* Video on failure */
    video: 'retain-on-failure',
  },

  /* Configure projects for major browsers */
  projects: [
    // DB reset and seeding
    { name: 'db-setup', testMatch: '**/db.setup.ts' },

    // Setup project for authentication
    { name: 'setup', testMatch: '**/auth.setup.ts', dependencies: ['db-setup'] },

    // Authenticated tests
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
        // Use prepared auth state.
        storageState: 'playwright/.auth/user.json',
      },
      dependencies: ['setup'],
    },
  ],

  /* Run your local dev server before starting the tests */
  webServer: {
    command: 'php artisan serve --port=8001',
    url: 'http://127.0.0.1:8001',
    reuseExistingServer: !process.env.CI,
    stdout: 'ignore',
    stderr: 'pipe',
  },
});

Playwrightでコンポーネント単位のPOMを導入し、テストで使い回す

Wed, 18 Feb 2026 07:06:37 +0900

Playwrightのページオブジェクトモデル（POM）とは、画面やボタンなどの部品をひとまとめにして管理する仕組みのことです。POMを使うことでテストコードがシンプルになり、またUI変更時にも修正がPOMファイルのみで済むといったメリットがあります。

そしてPOMは、ページ単位だけでなくコンポーネント単位でも導入可能です。この記事では、テストで繰り返し登場する入力項目をPOM化して、再利用できるようにしてゆきます。

POM化対象の要素

以下は食事管理アプリの一部の画面です。「食べたものを入力する画面」と「食材をDBに登録する画面」があり、赤枠内にあるカロリー、タンパク質などの入力項目複数が共通しています。実際には編集画面なども存在するため、この入力欄の使用頻度は高いです。

テストコードでも当然これらの入力欄が繰り返し登場するため、POM化するメリットは大きいです。

POM導入前のテストコード

以下は、POM導入前のテストコードです。「食べたものを登録する画面」と「食材をDBに登録する画面」それぞれで登録動作が正常に行えることをテストしています。

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

test.describe('POM使用前のテスト', () => {

  test('食べたものを登録', async ({ page }) => {
    await page.goto('/meals/create');

    // 今日の日付を設定
    const today = new Date().toISOString().split('T')[0];
    await page.getByLabel('日付').fill(today);

    await page.getByRole('radio', { name: '朝食' }).check();

    await page.getByLabel('料理名').fill('テスト朝食');
    await page.getByLabel('カロリー (kcal)').fill('500');
    await page.getByLabel('タンパク質 (g)').fill('20');
    await page.getByLabel('脂質 (g)').fill('15');
    await page.getByLabel('炭水化物 (g)').fill('60');
    await page.getByLabel('糖質 (g)').fill('55');

    await page.getByLabel('メモ').fill('テストメモ');

    await page.getByRole('button', { name: '保存して戻る' }).click();

    // ダッシュボードにリダイレクトされることを確認
    await expect(page).toHaveURL('/');
    // 成功メッセージが表示されることを確認
    await expect(page.getByText('食事を記録しました')).toBeVisible();
  });

  test('食材をDBに登録', async ({ page }) => {
    await page.goto('/food-compositions/create');

    await page.getByLabel('食材名').fill('じゃがいも');
    await page.getByLabel('カロリー (kcal)').fill('150');
    await page.getByLabel('タンパク質 (g)').fill('35');
    await page.getByLabel('脂質 (g)').fill('10');
    await page.getByLabel('炭水化物 (g)').fill('75');
    await page.getByLabel('糖質 (g)').fill('55');

    await page.getByRole('button', { name: '登録する' }).click();

    // ダッシュボードにリダイレクトされることを確認
    await expect(page).toHaveURL('/food-compositions');
    // 成功メッセージが表示されることを確認
    await expect(page.getByText('食材を登録しました。')).toBeVisible();
  });
});

前述の通りそれぞれのテストに同じ入力欄が存在しているため、getByLabel()による要素取得がずらずらと記述されています。

対象要素をPOM化する

早速ですが、以下が作成したPOMコンポーネントになります。POMファイルの置き場所に特にルールはありません。今回は、componentsというディレクトリを作成し、その中にファイルを配置しました。

e2e/components/NutritionInputs.ts

import { Page, Locator } from '@playwright/test';

/**
 * 栄養素入力フィールドの共通コンポーネント
 */
export class NutritionInputs {
  // すべてのロケーターをプロパティとして定義
  readonly nameInput: Locator;
  readonly caloriesInput: Locator;
  readonly proteinInput: Locator;
  readonly fatInput: Locator;
  readonly carbohydratesInput: Locator;
  readonly sugarInput: Locator;
  readonly saltInput: Locator;

  constructor(private page: Page) {
    this.nameInput = page.getByLabel(/(料理|食材)名/);
    this.caloriesInput = page.getByLabel('カロリー (kcal)');
    this.proteinInput = page.getByLabel('タンパク質 (g)');
    this.fatInput = page.getByLabel('脂質 (g)');
    this.carbohydratesInput = page.getByLabel('炭水化物 (g)');
    this.sugarInput = page.getByLabel('糖質 (g)');
    this.saltInput = page.getByLabel('塩分 (g)');
  }

  /**
   * すべての栄養素を一括入力
   */
  async fillAll(nutrition: {
    name: string;
    calories: string;
    protein?: string;
    fat?: string;
    carbohydrates?: string;
    sugar?: string;
    salt?: string;
  }) {
    // 各ロケーターを再利用して入力
    await this.nameInput.fill(nutrition.name);
    await this.caloriesInput.fill(nutrition.calories);
    if (nutrition.protein) await this.proteinInput.fill(nutrition.protein);
    if (nutrition.fat) await this.fatInput.fill(nutrition.fat);
    if (nutrition.carbohydrates) await this.carbohydratesInput.fill(nutrition.carbohydrates);
    if (nutrition.sugar) await this.sugarInput.fill(nutrition.sugar);
    if (nutrition.salt) await this.saltInput.fill(nutrition.salt);
  }
}

constructor()とfillAll()の２つの要素で構成されています。

まずconstructor()では、このコンポーネントで操作対象とする全ての入力項目をプロパティとして定義しています。page.getByLabel(/(料理|食材)名/);だけは正規表現で要素を指定していますが、これは画面によってラベル名が「料理名」と「食材名」のように異なるからです。

そしてfillAll()、こちらはメソッド名の通り全ての項目に入力を実行します。その際、先ほどのconstructor()で定義したthis.nameInput、this.caloriesInputなどのプロパティを使って操作を行います。

また、必須項目以外はif (nutrition.protein) ・・・として、データがある場合にのみ入力するようにしています。

今回は入力欄のみを扱っていますが、ボタンやリスト要素などももちろんPOM化できます。メソッドも自由に定義ですますので、詳しくは公式ドキュメントをご参照ください。

作成したPOMをテストコードで使う

このように作成したコンポーネントPOMをテストコード側でどのように使うかというと、以下のようにします。

import { NutritionInputs } from './components/NutritionInputs';

  test('食べたものを登録', async ({ page }) => {
    // コンポーネントPOMを直接作成
    const nutrition = new NutritionInputs(page);

    // コンポーネントのメソッドを使用して入力
    await nutrition.fillAll({
      name: 'じゃがいも',
      calories: '200',
      protein: '10',
      fat: '5',
      carbohydrates: '30',
      sugar: '15',
      salt: '1.0',
    });
・・・・・

まずはNutritionInputsをインスタンス化します。その際引数にpageオブジェクトを渡してください。そして、インスタンスを使ってfillAll()を呼び出します。

getByLabel()がずらっと並んでいた部分が、必要な情報を渡すだけという形にスッキリしました。もしも入力欄のラベル名が変更になっても修正はPOMファイル１箇所で済みます。

FixtureでPOMを定義する

これでPOMが使えるようになりましたが、テスト内にnewの記述が入ってしまうことが少し気になります。テストとは直接関係がないのでできればテストの外でnewしたい。

こういう場合、Fixtureが便利です。Fixtureとは、テストで使う共通の準備処理をまとめて定義できる機能のことです。

以下は作成したfixtureです。ドキュメントの記述にならって以下のようにしました。

e2e/fixtures.ts

import { test as base } from '@playwright/test';
import { NutritionInputs } from './components/NutritionInputs';

type MyFixtures = {
  nutritionInputs: NutritionInputs;
};

export const test = base.extend<MyFixtures>({
  nutritionInputs: async ({ page }, use) => {
    const nutritionInputs = new NutritionInputs(page);
    await use(nutritionInputs);
  },
});

export { expect } from '@playwright/test';

まず、このファイルで定義するPOMを宣言します。今回はnutritionInputsという名前でNutritionInputsを使えるようにしています。

そのあとbase.extend()でPlaywrightのtest()を拡張しています。POMのインスタンスを作成し、await use(nutritionInputs)によって、テスト側でnutritionInputsを使えるように渡す、という流れになっています。

これにより、テスト側では以下のようにtest()の引数にnutritionInputsを受け取るだけでPOMを使えるようになります。

import { test, expect } from './fixtures';

  test('食べたものを登録', async ({ page, nutritionInputs }) => {

    await nutritionInputs.fillAll({
      name: 'テスト朝食',
      calories: '500',
      protein: '20',
      fat: '15',
      carbohydrates: '60',
      sugar: '55',
      salt: '2.0',
    });
・・・・・

POM導入後のテストコード

作成したPOM・Fixtureを使用した、最終的なテストコードは以下になります。

import { test, expect } from './fixtures';

test.describe('NutritionInputsを使用', () => {
  test('食べたものを登録', async ({ page, nutritionInputs }) => {
    await page.goto('/meals/create');

    // 今日の日付を設定
    const today = new Date().toISOString().split('T')[0];
    await page.getByLabel('日付').fill(today);

    await page.getByRole('radio', { name: '朝食' }).check();

    //POMのメソッドで栄養素を一括入力
    await nutritionInputs.fillAll({
      name: 'テスト朝食',
      calories: '500',
      protein: '20',
      fat: '15',
      carbohydrates: '60',
      sugar: '55',
      salt: '2.0',
    });

    await page.getByLabel('メモ').fill('テストメモ');
    await page.getByRole('button', { name: '保存して戻る' }).click();

    // 保存後のリダイレクト・成功メッセージ確認
    await expect(page).toHaveURL('/');
    await expect(page.getByText('食事を記録しました')).toBeVisible();
  });

  test('食材DBを登録', async ({ page, nutritionInputs }) => {
    await page.goto('/food-compositions/create');

    // POMのメソッドを使用して入力
    await nutritionInputs.fillAll({
      name: 'じゃがいも',
      calories: '200',
      protein: '10',
      fat: '5',
      carbohydrates: '30',
      sugar: '15',
      salt: '1.0',
    });

    // ページ固有のボタン（Submitなど）は直接pageオブジェクトで操作
    await page.getByRole('button', { name: '登録する' }).click();

    // 保存後のリダイレクト・成功メッセージ確認
    await expect(page).toHaveURL('/food-compositions');
    await expect(page.getByText('食材を登録しました。')).toBeVisible();
  });
});

このように小さな単位からでもPOMを導入できるので、ぜひ使ってみてください！

ウェブからバックグラウンドでプログラムを実行

Sun, 08 Feb 2026 03:51:55 +0900

ウェブから時間がかかる作業、例えばアップロードした画像の整形などを行うときは、ジョブを作成してキュー使って非同期で実行するのが通常。しかし、Laravel 12.xからジョブをキューを使わずに即バックグラウンドで処理することが可能となりました。今回はその紹介です。

準備

まず使用するジョブを、Backgroundと命名して作成します。

app/Jobs/Background.php

namespace App\Jobs;

use Illuminate\Support\Facades\Log;
use Illuminate\Foundation\Queue\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;

class Background implements ShouldQueue
{
    use Queueable;

    /**
     * Create a new job instance.
     */
    public function __construct()
    {
        Log::info("バックグラウンドのジョブを作成");
    }

    /**
     * Execute the job.
     */
    public function handle(): void
    {
        Log::info('バックグラウンドのジョブの処理の開始');

        sleep(10);

        Log::info('バックグラウンドのジョブの処理の終了');
    }
}

このジョブの仕事は見ての通り、10秒間スリープすることですが、実際には代わりに画像の整形などの作業がプログラムされます。

それから、以下config/queue.phpにおいて以下の接続が入っていることを確認してください。

config/queue.php

...
    'connections' => [
...
        'deferred' => [
            'driver' => 'deferred',
        ],

        'background' => [
            'driver' => 'background',
        ],

        'failover' => [
            'driver' => 'failover',
            'connections' => [
                'database',
                'deferred',
            ],
        ],

    ],
...

ウェブと同じプロセスで同期実行（deferred）

同期実行と書くと、実行が完了するまで待たされること（上のジョブでは10秒のスリープ）を想像しますが、そうではなくウェブのレスポンスをユーザーに即座に返してからジョブが実行されます。つまり、画面で10秒待たされることはありません。

通常のジョブの発信は.envで、QUEUE_CONNECTION=sqsとかで指定したキューに以下のように発信します。

Background::dispatch();

しかし、deferredはdefaultのキューの接続を使わないので、onConnection()でdeferredを指定発信します。

Background::dispatch()->onConnection('deferred');

コントローラではこんな感じでコールします。

app/Controllers/BackgroundController.php

...
use App\Jobs\Background;
...

final class BackgroundController extends Controller
{
    public function create(): View
    {
        ...
        return view('create');
    }

    public function store(Request $request): RedirectResponse
    {
         Background::dispatch()->onConnection('deferred'); // ジョブを発信

         return redirect(route('background.create'));
    }
}

ウェブと違うプロセスで同期実行（background）

backgroundを使用したジョブの発信は、引数がbackgroundとなるだけです。

Background::dispatch()->onConnection('background');

deferredとの違いは、ジョブの処理はジョブを発信したウェブとはまったく違うプロセスで実行されます。ジョブを発信後に、Unixで馴染みなpsコマンドでプロセスをモニターしていると、以下のようにartisanのコマンド実行プロセスが新たに出てきます。

www-data 14961   340  4 19:49 ?        00:00:00 /usr/bin/php artisan invoke-serialized-closure

あたかも、ウェブからコマンドラインでコマンドを実行しているようです。

deferred vs background

さて、キューを使わないでバックグラウンドでジョブを処理できる方法を２つ紹介しましたが、どう使い分けたらいいのでしょうか。

２つの決定的な違いは、deferredではプログラムの実行時間がphpのmax_execution_timeの設定値に限られることです。プログラムの実行の40秒かかるとしてmax_execution_time=30としたら、実行開始してから30秒後に「Maximum execution time of 30 seconds exceeded」とようなエラーとなり処理が途中停止となってしまいます。

一方backgroundはあたかもコマンドライン(CLI)でコマンドを実行するように、そのような時間制限はありません。

必然的に、deferredは短めの作業の実行となり、backgroundは長めの作業に適するということになります。

この違いを実際にテストするには、先のBackgroundジョブを以下のように書き換えてdeferedとbackgroundの両方で発信してみてください。 sleep()がここで使われない理由は、スリープをいくら長くしてもはmax_execution_timeで指定する時間制限にカウントされないからです。

app/Jobs/Background.php

...
class Background implements ShouldQueue
{
    use Queueable;
...
    public function handle(): void
    {
        Log::info('バックグラウンドのジョブ処理の開始');
        $startTime = time();
        $lastLogTime = $startTime;

        while (true) {
            if (time() - $lastLogTime >= 10) {
                $secondsPassed = time() - $startTime;
                Log::info("実行中... ({$secondsPassed} 秒経過)");
                $lastLogTime = time();
            }

            if (time() - $startTime > 40) {
                break;
            }
        }

        Log::info('バックグラウンドのジョブ処理の終了');
    }
}

ミドルウェアをもっと知ろう（４）コントローラに装着

Sun, 25 Jan 2026 06:43:46 +0900

Laravelでは、カスタムに作成したミドルウェアをいろいろな場所で装着することができとてもフレキシブルです。前回ではグローバルやルートで装着しました。今回はLaravel 11.xバージョンから追加されたコントローラでのmiddlewareメソッドで装着してみます。

カスタムに作成したミドルウェア

前回から結構時間が経過しているので、まずそこで作成したミドルウェアのコードを持ち出します。

app/Http/Middleware/HideForbiddenWords.php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Support\Str;
use Illuminate\Http\Request;

class HideForbiddenWords
{
    public static $forbiddenWords = ['禁止１', '禁止２', '禁止３'];

    public function handle(Request $request, Closure $next): mixed
    {
        // 禁止用語を***に変換
        $all = $request->collect()->map(function ($value, $key) {
            return is_string($value) ? Str::of($value)->replace(static::$forbiddenWords, '***')->toString() : $value;
        })->all();

　　　　// もとのリクエストを置き換える
        $request->merge($all);　

        return $next($request);
    }
}

このミドルウェアは、$forbiddenWords配列で設定した３つの禁止用語が入力にあれば、***に変換します。

グローバルでの装着

こちらも前回からのコピーですが、今回のようなローカルなミドルウェアには向いていないです。

bootstrap/app.php

use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->append(
            \App\Http\Middleware\HideForbiddenWords::class,
        );
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

ルートで装着

以下のようにルートの定義で装着するのが現実的です。特定のコントローラの特定のルートに装着できます。

use App\Http\Middleware\HideForbiddenWords;

Route::patch('/profile', [ProfileController::class, 'update'])
    ->name('profile.update')
    ->middleware(HideForbiddenWords::class);

コントローラで装着

こちら、Laravelの11.xバージョン以降では、以下のようにmiddlewareのメソッド内でも指定できます。

app/Http/Controllers/ProfileController.php

namespace App\Http\Controllers;

use App\Http\Requests\ProfileUpdateRequest;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Routing\Controllers\HasMiddleware;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Redirect;
use Illuminate\View\View;

class ProfileController extends Controller implements HasMiddleware
{
    public static function middleware(): array
    {
        return [\App\Http\Middleware\HideForbiddenWords::class];
    }

    /**
     * Display the user's profile form.
     */
    public function edit(Request $request): View
    {
        return view('profile.edit', [
            'user' => $request->user(),
        ]);
    }

    /**
     * Update the user's profile information.
     */
    public function update(ProfileUpdateRequest $request): RedirectResponse
    {
        $request->user()->fill($request->validated());

        if ($request->user()->isDirty('email')) {
            $request->user()->email_verified_at = null;
        }

        $request->user()->save();

        return Redirect::route('profile.edit')->with('status', 'profile-updated');
    }
...

注意点として、

use Illuminate\Routing\Controllers\HasMiddleware;の宣言が必要なこと。
middlewareのメソッドは、staticであること。ゆえにその中では、$this->nameのようなインスタンス変数への使用は不可です。

を忘れずに。

ちなみに、Laravel 10.xバージョン以前では、HasMiddlewareはまだ登場していないので、以下のようにコンストラクターでコールしていました。

app/Http/Controllers/ProfileController.php

...
class ProfileController extends Controller
{
    public function __construct()
    {
        $this->middleware(\App\Http\Middleware\HideForbiddenWords::class);
    }
...
}

PlaywrightでE2Eテストを自動化（５）Authenticationでログイン処理を簡略化

Mon, 19 Jan 2026 03:11:09 +0900

以前にご紹介したPlaywrightテスト作成の記事では、一連のログイン動作を共通処理として関数化し、使いまわせるようにしました。この方法ではコード上はすっきりしますが、ログイン処理がテストごとに実行される点は同じです。

そこで今回は、PlaywrightのAuthenticationを使って「認証状態」自体を使いまわせるようにしてゆきます。毎回ログイン処理を行う必要がなくなるので、テスト時間の短縮が期待できます。

関連記事：PlaywrightでE2Eテストを自動化（２）ログイン・ログアウト

Authenticationとは

Authenticationは、認証済みのブラウザ状態をファイルに保存し、各テストの実行時に読み込ませることで「ログイン済み」の状態からテストを開始できる仕組みです。認証を使用する流れは、簡単に書くと以下のようになっています。

セットアップ用ファイル（auth.setup.ts）を作成し、playwright.config.tsに定義する
テスト開始前に１のセットアップが実行されると、ログイン処理と共にuser.jsonにログイン状態が保存される
テストのstorageStateオプションにuser.jsonを指定することで、ブラウザが認証済みの状態で起動する

注意点は、「サーバー側のセッションデータ」は共有されないということです。PlaywrightのAuthenticationは「ブラウザのクッキー」を保存・再利用する仕組みのため、ログアウトのようなサーバー側のセッションを削除する操作を行うと、同じクッキーを使っている他のテストでも認証が切れてしまいます。

この問題を避けるため、ログアウトのテストでは他のテストとアカウントを分けることが推奨されています。

Authenticationの設定方法

ではAuthenticationを設定します。今回は、任意のテストファイルやテストグループに対してのみ認証を適用する形にしたいので、それを目標に進めてゆきます。

playwright/.auth ディレクトリの作成

認証状態を保存するuser.jsonファイル自体は、セットアップ実行時に自動で作成されます。ですがファイルを保存するディレクトリ（Playwrightではplaywright/.auth推奨）は作成されないため、無い場合は以下のコマンドで事前に作成します。

また、機密情報を持つファイルをリポジトリに含めないよう、.gitignoreにディレクトリを追加します。

$ mkdir -p playwright/.auth
$ echo $'\nplaywright/.auth' >> .gitignore

セットアップ用ファイルを作成

次に、セットアップファイルを作成します。auth.setup.tsという名前のファイルを作成し、以下のように記載します。

e2e/auth.setup.ts

import { test as setup } from '@playwright/test';

const authFile = 'playwright/.auth/user.json';

setup('認証情報を保存', async ({ page }) => {

    await page.goto('/login');

    await page.getByLabel('メールアドレス').fill(process.env.TEST_EMAIL!);
    await page.getByLabel('パスワード').fill(process.env.TEST_PASSWORD!);
    await page.getByRole('button', { name: 'ログイン' }).click();

    // ログイン成功を確認
    await page.waitForURL('/user/diary');

    // 認証状態を保存
    await page.context().storageState({ path: authFile });
});

ログイン動作自体は通常のPlaywrightのブラウザ操作と同じ書き方です。重要なのは、コードの最後のpage.context().storageState({ path: authFile });の箇所です。user.jsonのパスを渡し、認証状態を保存しています。

Playwrightのドキュメントによると、ログイン動作後すぐに認証状態を保存するのではなく、上のコードのawait page.waitForURL(’/user/diary’);のように、確実にログインしたことを確認するコードを挟んだ後で保存することがおすすめのようです。

configファイルに定義

playwright.config.tsに、作成したセットアップファイルを定義します。

playwright.config.ts

・・・・・
  projects: [
    {
      name: 'setup',
      testMatch: /.*auth\.setup\.ts/,
    },
    {
      name: 'chromium',
      dependencies: ['setup'], // 先にsetupを実行
      use: { ...devices['Desktop Chrome'] },
    },
・・・・・

name: ‘setup’でセットアップ用のプロジェクトを定義し、dependencies: [‘setup’]では、chromiumのテスト実行前にsetupを実行することを定義しています。dependencies: [‘setup’]はブラウザごとに記述する必要があるので、firefoxやwebkitなども使用する場合はそちらにも追記してくださいね。

テストファイルでuseする

最後に、認証ファイルを任意のテストで読み込みます。以下のようにtest.use()を使い、認証ファイルへのパスを記載します。

e2e/authenticated.spec.ts

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

test.describe('ログイン済みユーザーを使ったテスト', () => {

    test.use({ storageState: 'playwright/.auth/user.json' }); //認証ファイルのパスを指定

    test('ダッシュボードの表示', async ({ page }: { page: Page }) => {

        // すでにログイン済みの状態からテストを開始できる
        await page.goto('/user/diary');
・・・・・
    });
});

test.use()の記述位置ですが、個々のtest()の中に書くとエラーとなりますので、上の例のようにtest()の外に配置してください。そうすると、test.describe()のグループ全体、またはそのテストファイル全体に認証状態が適用されます。

テストの実行時

先ほどのauth.setup.tsでは、メールアドレス・パスワードなどログインに使う情報を、環境変数（process.env）として取得していました。そのためテスト実行時には、ターミナルで以下のコマンドを実行して環境変数をセットしてください。

$ export TEST_EMAIL=test@example.com; export TEST_PASSWORD=password
$ npx playwright test

exportコマンドはMacやLinux環境を想定しています。Windowsをお使いの場合は、ご利用のシェルに合わせて適宜コマンドを読み替えて実行ください。

全体を認証済みとし、特定のテストだけ認証状態をリセットする場合

先ほどの例では任意のテストでのみ認証状態を使用しましたが、テスト全体はログイン済みの状態とし、一部のテストでのみ未ログイン状態としたい場合もあるかと思います。

そのような場合は、以下のようにplaywright.config.tsで全体に認証情報を設定します。適用したいブラウザ（ここではchromium）プロジェクトのuseオプションに、storageStateとしてuser.jsonファイルを追加します。

playwright.config.ts

・・・・・
  projects: [
    {
      name: 'setup',
      testMatch: /.*auth\.setup\.ts/,
    },
    {
      name: 'chromium',
      dependencies: ['setup'],
      use: {
        ...devices['Desktop Chrome'],
        // 認証データを使用
        storageState: 'playwright/.auth/user.json', // ここを追加
      },
    },
・・・・・

そして認証を使いたくないテストファイルでは、以下のようにtest.use()でstorageStateの状態をクリアします。

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

test.describe('未ログインユーザーのテスト', () => {

    test.use({ storageState: { cookies: [], origins: [] } });

    test('ログイン成功', async ({ page }: { page: Page }) => {
・・・・・
    });
});

テスト時間が変わるのか確認

では、Authenticationを使うことでテスト実行時間に影響があるか確認してみます。対象のテストにはログイン処理を実行する箇所が８箇所あり、これらをAuthenticationを使う形に修正しました。比較するにはテスト数が少ないですが、これでやってみます。

まずはAuthentication導入前、ログイン処理が８箇所あるテストを実行してみます。

$ npx playwright test

Running 11 tests using 4 workers
・・・・・
  11 passed (8.6s)

８.６秒でテストが完了しました。

次に、Authenticationによる認証状態を使用したコードでテストを実行します。

$ npx playwright test

Running 11 tests using 4 workers
・・・・・
  11 passed (5.9s)

今度は５.９秒でテストが完了しました。念のためテストをそれぞれ複数回実行しましたが、後者のテストのほうが常に２秒以上短い時間でテストが完了する結果となりました。

たった８箇所に認証状態を適用しただけで２〜３秒テスト時間が短縮できたので、テスト数が多ければ恩恵は大きいと思います。なによりログイン部分を省略してすっきり書けますので、Playwrightを使用している方はぜひ試してみてください。

開発のタスクを整理するためのツール

Wed, 17 Dec 2025 07:48:04 +0900

開発に関わるタスクとして手動で実行するコマンドは日に日に増える一方です。Laravelのシンプルなプロジェクトでも、コード作成後にはpint（コード自動整形ツール）、PHPStan（静的解析ツール）、そしてpest（テスト）を必ず実行します。また、ブラウザで動作チェックするために

ローカル環境を立ち上げるコマンドたち、さらに、gitのようなバージョン管理のためのコマンド実行もあります。問題はこれらのコマンドすべてを覚えるのは大変なのと、いくつかのコマンドは１つ１つタイプして実行するより、まとめて実行して簡素化もしたいです。つまり、タスクを整理するツールは必須です。今回はこれらのツールの紹介です。

開発に必要なタスクの種類

まず、私の開発環境をもとにして、どのようなタスクがあるかグループして整理してみます。

コード作成後に実行するタスク

コード自動整形ツール：pint、rector
静的解析ツール：phpstan
テストツール：phpunit、pest
バージョンコントロール：git commit, push, branch, mergeなど

ローカル開発環境を立ち上げるタスク

コンテナ―の立ち上げ：sail up
ウェブサーバー：php artisan server
CSSやスクリプトのビルド・ホットリロード：npm run dev

これらを実行して、ブラウザーでの動作確認が可能となります。

インストール作業のためのタスク

バージョンコントロール：git pull
ライブラリのインストール：　composer install
データーベース変更：php artisan migrate
キャッシュの作成：php artisan config:cache, event:cache, route:cache

他にも、ログのチェックのために単に、less storage/logs/laravel.logの実行とかもありますね。

さて、これらを整理するツールを紹介です。

composer

composerは基本的にはphpのプロジェクトで使用するパッケージを管理するコマンドですが、新規のLaravelプロジェクトをインストールすると、以下のように、composer.json内に"scripts"のセクションがあり、いくつかのタスクがグループされて実行を可能としています。

composer.json

{
...
   "scripts": {
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ],
        "post-update-cmd": [
            "@php artisan vendor:publish --tag=laravel-assets --ansi --force"
        ],
        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate --ansi",
            "@php -r \"file_exists('database/database.sqlite') || touch('database/database.sqlite');\"",
            "@php artisan migrate --graceful --ansi"
        ],
        "dev": [
            "Composer\\Config::disableProcessTimeout",
            "npx concurrently -c \"#93c5fd,#c4b5fd,#fb7185,#fdba74\" \"php artisan serve\" \"php artisan queue:listen --tries=1\" \"php artisan pail --timeout=0\" \"npm run dev\" --names=server,queue,logs,vite"
        ],
        "test": [
            "@php artisan config:clear --ansi",
            "@php artisan test"
        ]
    },
...

例えば、

$ composer dev

を実行すれば、以下のコマンドを、

ウェブサーバーの起動：php artisan server
キューを継続的にモニター・処理：php artisan queue
ログをモニター：php aritsan pail
CSSやスクリプトのビルド・ホットリロード：npm run dev

皆いっぺんに並行実行します。以下は実行時のコマンド画面です。

つまり、composer.jsonのファイルを編集して、自由に必要なタスクのコマンドをグループ化して実行が可能というわけです。

npm

npmは、composerと違ってphpではなくjs関連のパッケージの管理ツールですが、composerと同様に、package.jsonに"script"のセクションがあり、先のようなグループタスクを以下のように設定が可能です。

{
    "private": true,
    "type": "module",
    "scripts": {
        "build": "vite build",
        "dev": "vite",
        "start": "concurrently -c \"#93c5fd,#c4b5fd,#fb7185,#fdba74\" \"php artisan serve\" \"php artisan queue:listen --tries=1\" \"php artisan pail --timeout=0\" \"npm run dev\" --names=server,queue,logs,vite"
    },
...

実行は、以下のコマンドとなります。

$ npm run start

make

C言語のプログラマー（昔は誰しもそうであった）ならとても馴染みのあるmakeコマンドは、タスクコマンドの整理にも使用できます。

makeの典型的な使用は、まずMakefileを作成して、そこでターゲットとソースコードの依存を指定し、それを作成するためのコマンドを記述します。

例えば、以下では、

Makefile

foo: foo.c
	cc foo.c -o foo

１行目は、ターゲットは実行可能なファイル、fooであり、その生成のためにC言語のソースコード、foo.cに依存することを示します。もし、foo.cがfooより古いあるいは存在しないなら、２行目以降に指定されたコマンドを実行します。そこでは、ccはＣのコンパイラーが記述されていて、-oで生成されるバイナリーのファイル名を指定されています。この２行目では必ず、行先頭にタブ文字を含むことが必要です。空白文字ではだめです。結構センシティブなので注意を。

この実行は、

$ make

となります。

さて、このMakefileでは、コンパイルでなくとも他のタスクの指定にも使うことが可能です。以下では、先のcomposer.jsonやpackage.jsonのように、ブラウザチェックのために必要なコマンドの起動を指定します。

Makefile

.PHONY: dev

dev:
	npx concurrently -c "#93c5fd,#c4b5fd,#fb7185,#fdba74" \
	"php artisan serve" \
	"php artisan queue:listen --tries=1" \
	"php artisan pail --timeout=0" \
	"npm run dev" \
	--names=server,queue,logs,vite

最初の.PHONY: devは、devが先のCソースコードのコンパイルの例とは異なりターゲットがファイルではないこと意味します。また、dev:の行は、ターゲット名のみであり、その依存元はありません。そして、続く行は実際に実行されるコマンドです。これはcomposerやnpmと同様です。しかし、バックスラッシュを使用して改行できたり、コマンドすべてを引用符で囲む必要もないので読みやすくできます。

私がmakeが好きなのは、開発のタスクの実行コマンドを、パッケージ管理が使用目的のcomposer.jsonやpackage.jsonから明確に分けることができること、そしてbashなどのシェルスクリプトでよく使われる変数、条件式、ループを取り入れることも可能です。、さらにLaravelで使用する.envも読み込むことも可能なことです。

例えば、.envと.env.exampleを比べて使う変数名に漏れがないか調べるには、Makefileを以下のように設定できます。

Makefile

include .env

ENV_EXAMPLE=`grep '=' .env.example | awk -F'=' '{ print $$1}' | sort -u`
ENV_ACTUAL=`grep -v '^\#' .env | grep '=' | awk -F'=' '{ print $$1}' | sort -u`

env:
	for i in $(ENV_ACTUAL); do \
		if ! grep -q "^$$i=" .env.example; then echo "not found $$i in .env.example"; fi; \
	done; \
	for i in $(ENV_EXAMPLE); do \
		if ! grep -q "^$$i=" .env; then echo "not found $$i in .env"; fi; \
	done

Pest4のE2Eテスト - セットアップ〜テストコードの実装例

Wed, 10 Dec 2025 07:22:45 +0900

Pest4からブラウザテスト機能が追加され、簡単なセットアップだけでPlaywrightを使ったE2Eテストが使えるようになりました。今回はLaravelで作成したプロジェクトを使って、セットアップからテストコード作成までの流れを実際に試してみます。

セットアップ

私の環境ではユニットテストとしてすでにPestを導入済みですが、もしPHPUnit環境の方は移行に関する以下の記事もご参照ください。

LaravelのPHPUnitテストをpest-plugin-driftでPestへ変換

ブラウザテストはPest v4系で利用できるため、まずPestを更新します。

$ composer require pestphp/pest --dev --with-all-dependencies

v4.1.4に更新されました。次にブラウザテスト用のプラグインをインストールします。

$ composer require pestphp/pest-plugin-browser --dev

そして、Playwright本体とブラウザをインストールします。

$ npm install playwright@latest
$ npx playwright install

次に、スクリーンショットの保存ディレクトリをgitignoreに追記します。ドキュメントに記載の通り、テスト実行時に生成されるスクリーンショットをGit管理から外しておくためです。

保存先はブラウザテストのディレクトリによって変わります。私の環境ではtests/Browserにテストを配置するため、以下のようになります。

.gitignore

...
tests/Browser/Screenshots

ここまでで準備は完了です。動作確認用に、画面遷移・表示確認だけの以下のようなシンプルなテストを作成しました。

tests/Browser/BrowserTest.php

it('example', function () {
    $page = visit('/');
    $page->assertSee('Laravel');
});

テストを実行します。テスト用のサーバーが自動で起動するので、php artisan serveは不要です。

$ ./vendor/bin/pest tests/Browser/BrowserTest.php

   FAIL  Tests\Browser\BrowserTest
  ⨯ it example                  0.04s  
  ────────────────────────────────────────────────  
   FAILED  Tests\Bro…  BindingResolutionException   
  Target class [config] does not exist.

テストが失敗してしまいました。新しく作成したBrowserディレクトリが、Pestの設定ファイルに追加されていないことが原因のようです。

Pest.phpを以下のように修正しました。Browserを追加しています。

tests/Pest.php

pest()->extend(Tests\TestCase::class)
・・・
    ->in('Feature', 'Browser');

もう一度テストを実行してみます。

$  ./vendor/bin/pest tests/Browser/BrowserTest.php

   PASS  Tests\Browser\BrowserTest
  ✓ it example                  1.33s  

  Tests:    1 passed (1 assertions)
  Duration: 1.99s

テストが通りました！これで準備完了です。

新規作成フロー・テストコード全体

セットアップが整ったので、ここでは実際に作成したブラウザテストのコード全体を先にご紹介します。

テスト対象は前回も使用した英語日記アプリの新規作成機能です。

新規作成は３段階の画面遷移になっており、「日本語入力画面 → 英訳を入力・AI翻訳を実行 → 確認して保存」という流れになっているので、テストでは各画面でのテキスト入力や遷移の動作を確認しています。

また１日の入力文字数には制限があるので、入力したテキストの文字数によって文字数のカウント表示が正確に更新されているか、も確認しています。

use App\Models\User;

it('日記新規作成', function () {

    User::factory()->create([
        'email' => 'test@example.com',
        'password' => bcrypt('password'),
    ]);

    // ログインページへ移動
    $page = visit('/login');

    // メールアドレスとパスワードを入力
    $page->fill('email', 'test@example.com')
        ->fill('password', 'password')
        ->click('ログイン')
        ->assertPathIs('/user/diary');

    // 新規作成ページへ移動
    $page->click('a[href*="/diary/create"]')
        ->assertPathIs('/user/diary/create');

    // 入力テキストを準備
    $japaneseText = '今日は素晴らしい一日でした。';
    $englishText = 'Today was a wonderful day.';

    // 文字数カウンター確認用に、入力前の残り文字数を取得
    $initialRemaining =  (int)$page->text('#char_count');

    $inputLength = mb_strlen($japaneseText);
    $expectedRemaining = $initialRemaining - $inputLength;

　　 // 画面１: 日本語で入力
    $page->fill('native_content', $japaneseText)
        // 文字数カウンターの確認（計算した値と一致するか）
        ->assertSee("残り文字数: {$expectedRemaining}")
        ->click('次へ！');

    // 画面２: 英訳を入力
    $page->assertSee('英語で書いてみよう！')
        ->fill('user_translation', $englishText)
        ->click('翻訳する');

    // 翻訳中の画面表示が消えるまで待機
    $page->page()->getByText('翻訳中...')->first()->waitFor(['state' => 'hidden']);

    // 画面３への遷移待機
    $page->wait(1);

    // アサートに必要なデータの取得
    $aiTranslation = $page->value('translated_content');
    expect($aiTranslation)->not->toBeEmpty('AI翻訳結果が空です');

    // 画面３: 保存
    $page->click('保存')
        ->assertSee('日記が作成されました。')
        // 詳細画面での表示確認
        ->assertSee($aiTranslation)
        ->assertSee($japaneseText);
});

複数の画面遷移を含むのでコードは少し長めですが、メソッド名はどれもシンプルで分かりやすいので流れは追いやすいかと思います。

では続いて、今回のテストで使用したメソッドをまとめます。

画面遷移・操作系メソッド

まず、画面遷移にはvisit()を使用します。pageオブジェクトが返るので、後続のコードでは$pageを元に、画面を操作したりアサートしたりする形になります。

$page = visit('/login');

入力・クリック操作は、fill()・click()を使用します。

$page->fill('email', 'test@example.com')
    ->fill('password', 'password')
    ->click('ログイン')

上記のコードでは、email・passwordというname要素に指定の文字列を入力後、ログインボタンをクリックしています。

また指定の時間待機したい時はwait()を使用し、引数に秒数を渡します。

$page->wait(1);

要素の値を取得するメソッド

次に、要素の値を取得する時は、text()・value()を使用します。

text()は、HTML要素内のテキストを取得します。以下の例では、idにchar_countを持つ要素からテキストを取得しています。

$initialRemaining = $page->text('#char_count');

またvalue()は、input・textarea・selectなどフォーム要素のvalue値を取得します。以下のコードでは、idがtranslated_contentという要素から文字列を取得しています。

$aiTranslation = $page->value('translated_content');

セレクタの指定について

ここまでの例で、セレクタの指定方法が複数混在していることに気づかれた方もいるかもしれません。

text(’#char_count’)のようにid明示するケースや、click(‘a[href*="/diary/create"]’)のようにcssセレクタを直接指定する書き方、click(‘ログイン’)のように文字列だけを渡しているケースなどがあります。

これはPestで定義されているGuessLocator機能のおかげです。GuessLocatorは、以下の優先順位で引数の情報から自動で要素を選択してくれます。

#や.で始まる場合 → CSSセレクタとしてそのまま使用
@で始まる場合 → data-testid/data-test属性として検索
通常の文字列の場合 → id、name属性として検索
上記で無い場合は文字列として要素を検索

こちらの詳細は、vendor/pestphp/pest-plugin-browser/src/Support/GuessLocator.phpに定義されています。

アサーション系

続いてアサーションです。URLの確認には、以下のようにassertPathIs()を使用します。

$page->click('ログイン')
    ->assertPathIs('/user/diary');

またassertSee()では、ページ内に引数のテキストが表示されているかを確認します。

$page->assertSee("日記が作成されました。");

使用可能なLaravelのメソッド

Pest4のブラウザテストでは、Laravelのテストヘルパーメソッドも使用できます。

先ほどのテスト内で使用しているfactory()だけでなくactingAs()・assertAuthenticated()なども使えるので、ユーザーログインの手順をスキップしたい場合は以下のように簡略化できて便利です。

    $user = User::factory()->create([
・・・
    ]);

    $this->actingAs($user);
    $this->assertAuthenticated();
・・・

Playwrightのメソッドを使いたい場合

最後に、Pestのメソッドだけでは対応できない場合についてご紹介します。

今回のテストでは「特定の要素が非表示になるまで待機」という処理が必要でしたが、Pestの標準メソッドにはPlaywrightのwaitFor()に該当する機能がありませんでした。このような場合は、page()メソッドを使ってPlaywrightオブジェクトに直接アクセスできます。

    $page->page()->getByText('翻訳中...')->first()->waitFor(['state' => 'hidden']);

このコードでは、「翻訳中…」というテキストを持つ要素を取得し、その要素がhiddenになるまで待機させる処理を、Playwrightオブジェクトを経由して実行しています。

まとめ

テストコードの書き方自体は、CypressやPlaywrightを単体で使う場合と比べても大きな違いはないかなと思いました。

ただ今回のPest4はLaravelのテストとしてブラウザテストをプロジェクトに統合できるため、factoryでのテスト用レコードの生成や、認証ヘルパーなどがそのままE2Eテストに使用できます。その点が他と比べてもとても便利だと感じました。

第２のデータベースにアクセス

Fri, 14 Nov 2025 12:04:49 +0900

たいていのプロジェクトで扱うデータベースは１つですが、これが２つあるいは３つのデータベースにアクセスするとなったら、どう対応するのでしょう？というのが今回のテーマです。

データベースのコネクション

まず、データベースのコネクションに関しての説明です。扱うデータベースが１つとすると、

.env

...
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=db1
DB_USERNAME=root
DB_PASSWORD=password
...

と設定します。これらの環境変数は、以下のconfig/database.phpにおいてのデータベース接続のための値となります。

config/database.php

return [

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [

        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DB_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'laravel'),
            'username' => env('DB_USERNAME', 'root'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => env('DB_CHARSET', 'utf8mb4'),
            'collation' => env('DB_COLLATION', 'utf8mb4_unicode_ci'),
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

扱うデータベースが２つのとき

デフォルトのデータベースへのコネクションが、mysqlとすると、もう１つ扱うデータベースを mysql2 として、先のconfig/database.phpに追加することができます。

config/database.php

return [

    'default' => env('DB_CONNECTION', 'mysql'),

    'connections' => [
      　 // デフォルトのデータベース
        'mysql' => [
        ...
        ],

　　　　// 第２のデータベース
        'mysql2' => [
            'driver' => 'mysql',
            'url' => env('DB2_URL'),
            'host' => env('DB2_HOST', '127.0.0.1'),
            'port' => env('DB2_PORT', '3306'),
            'database' => env('DB2_DATABASE', 'laravel'),
            'username' => env('DB2_USERNAME', 'root'),
            'password' => env('DB2_PASSWORD', ''),
            'unix_socket' => env('DB2_SOCKET', ''),
            'charset' => env('DB2_CHARSET', 'utf8mb4'),
            'collation' => env('DB2_COLLATION', 'utf8mb4_unicode_ci'),
            'prefix' => '',
            'prefix_indexes' => true,
            'strict' => true,
            'engine' => null,
            'options' => extension_loaded('pdo_mysql') ? array_filter([
                PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
            ]) : [],
        ],
...

mysql2では、環境関数名は皆DB2_のプレフィックスとなっていることに注意を。

.envでは、こんな感じに設定します。

.env

...
DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=db1
DB_USERNAME=root
DB_PASSWORD=password

DB2_HOST=localhost
DB2_PORT=3307
DB2_DATABASE=db2
DB2_USERNAME=root2
DB2_PASSWORD=password2
...

第２のデータベースにアクセスするには

さて、第２のデータベースにアクセスしてみましょう。

クエリビルダーでは、以下のようにconnection()の引数に第２のデータベースのコネクション mysql2 を指定するだけです。

DB::connection('mysql2')->table('user')->get();

Eloquentではどうでしょう。

まず、第２のデータベースのモデルを作成します。

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class RemoteUser extends Model
{
    protected $table = 'users';

    protected $connection = 'mysql2'; // ここでコネクションを指定
}

ここでは、デフォルトのデータベースと同じように、第２のデータベースでも users というテーブルが存在すると仮定します。通常と違って、mysql2のコネクションが指定されていることも注意を。

この設定なら、クエリの実行はデフォルトのデータベースのEloquetとまったく変わりません。簡単ですね。

RemoteUser::all();

Eloquentで動的にコネクションを指定

先のEloquentはモデル内ですでに指定されている固定のコネクションでしたが、前もってわからないときはどうしましょう。つまりモデルの定義が以下のようなときのことです。

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class RemoteUser extends Model
{
    protected $table = 'users';
}

このようなときは、クエリ実行時において、以下のようにコネクションを指定します。

RemoteUser::on('mysql2')->get();

上では、RemoteUser::on(‘mysql2’)は、Illuminate\Database\Eloquent\Builderを返すので、RemoteUser::on(‘mysql2’)::all()とは出来ないことに注意を。

PlaywrightでE2Eテストを自動化（４）Agents × Claude Code

Thu, 30 Oct 2025 11:35:59 +0900

Playwrightから新しくAgents機能がリリースされました。テストプランの作成・テストコードの作成・エラーとなったテストの修正を行なう、３つのエージェント機能を備えています。今回は、Claude CodeとAgentsを使ってLaravelプロジェクトにE2Eテストを追加してみます。

テスト対象のサイト

テスト対象のサイトについて簡単にご紹介します。よくある「英語日記」のような機能で、ログイン後のダッシュボードでは日記一覧の表示・音声再生・詳細画面への遷移ができます。

新規作成は３段階の画面遷移になっており、「日本語で入力 → 英語で入力 → 最後にAIが文章を翻訳・添削してアドバイスを返す」という流れになっています。

準備・セットアップ

ではさっそくAgentsを使う準備から進めてゆきます。

Playwrightのインストールがまだの方は、セットアップの記事をご覧ください。

私の環境ではすでにPlaywrightがインストール済みですが、Agentsは新しい機能のため、バージョンアップが必要かもしれません。プロジェクトのルートディレクトリで以下のコマンドを実行します。

$ npm install -D @playwright/test@latest 
$ npx playwright --version  
Version 1.56.0

執筆時点で最新の1.56.0に更新されました。

次に、以下のコマンドを実行します。この記事ではClaude Codeを使用するので、オプションでclaudeを指定します。

$ npx playwright init-agents --loop=claude

Claude Code以外を使用する方はドキュメントからコマンドをご確認ください。

コマンド実行後、新規に以下の５ファイルが作成されました。

Writing file: .claude/agents/playwright-test-generator.md
Writing file: .claude/agents/playwright-test-healer.md
Writing file: .claude/agents/playwright-test-planner.md
Writing file: .mcp.json
Writing file: e2e/seed.spec.ts

.claude/agents/ディレクトリには３種類のエージェントに関するファイルが生成され、それぞれのエージェントは以下のような役割になっています。

playwright-test-planner.md ：テスト計画を作成するエージェント
playwright-test-generator.md ：テストコードを生成するエージェント
playwright-test-healer.md ：テストを修復するエージェント

また、テストディレクトリにインストールされたe2e/seed.spec.tsを見てみると、初期状態では以下のように特に内容のないファイルとなっています。

e2e/seed.spec.ts

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

test.describe('Test group', () => {
  test('seed', async ({ page }) => {
    // generate code here.
  });
});

こちらはグローバルセットアップや依存関係、またはエージェントへの指示を記述するファイルで、Playwrightの各エージェントから参照されます。実際の運用時には重要となるファイルですが、今回は初期状態のまま進めます。

plannerでテストプランを作成

ここからClaude Codeを使ってゆきます。Claude Codeを起動すると、次のようなメッセージが表示されました。

New MCP server found in .mcp.json: playwright-test                                                                                                                      │
│                                                                                                                                                                         │
│ MCP servers may execute code or access system resources. All tool calls require approval. Learn more in the MCP documentation                                           │
│ (https://docs.claude.com/s/claude-code-mcp).                                                                                                                          │
│                                                                                                                                                                         │
│ ❯ 1. Use this and all future MCP servers in this project                                                                                                                │
│   2. Use this MCP server                                                                                                                                                │
│   3. Continue without using this MCP server

先ほど作成された.mcp.jsonに記載のMCPサーバー（playwright-test）は、コード実行やシステムリソースへのアクセスを行うため、セキュリティ確認が求められているようです。今回は２番の「このMCPサーバーを使用」を選択しました。

ここからやっとプランの作成に入りますが、その前にテスト対象サイトにアクセスできる状態かを確認します。今回はローカルにあるLaravelプロジェクトを対象としているため、サーバーを起動させておきます。

$ php artisan serve

プラン作成用エージェントを実行すると、ブラウザが起動してPlaywrightが実際にサイトを操作しながらテストプランを作成します。そのため、あらかじめ起動しておく必要があります。

Claude Codeへのプロンプトは以下のように記述しました。@agent-playwright-test-plannerのように"@“付きで明示的にエージェントを起動してもいいですし、以下のように文章のみで渡しても問題なく認識されました。

$ playwright-test-plannerエージェントを使って次のテストプランを作成ください。ログイン後のダッシュボード画面での日記一覧表示・新規作成・翻訳機能

すると、以下のようにplaywright-test-plannerが起動しました。

プランナー起動時のスクリーンショット

しばらく待つとプラン作成完了のメッセージが表示されました。メッセージが長いので冒頭のみですが、以下のような形で作成したプランの概要を知らせてくれます。

⏺ テストプランの作成が完了しました！

  作成されたファイル

  1. 詳細テストプラン (e2e/test-plan-dashboard.md)

  600行以上の詳細なドキュメントで、以下を含みます：
  - 70以上のテストシナリオ
  - 12のテストカテゴリ：
    - 認証とログイン
    - 日記一覧表示
    - 日記詳細表示
    - 日記新規作成（3ステップ）
    - 翻訳機能
    - セキュリティとバリデーション
    - UI/UX
    - エッジケースとエラー処理など

  2. 要約版 (e2e/test-plan-summary.md)

  エグゼクティブサマリーで、以下を含みます：
  - 発見された主要機能
  - テストシナリオの優先度
  - 技術スタック分析
  - 推奨される次のステップ
・・・・・

実際のテストプランはtest-plan-dashboard.mdに出力されており、テスト概要 → シナリオ → 成功基準という構成で書かれていて読みやすいです。こちらも一部を抜粋します。

#### 1.1 ログイン後の正常なページロード
**手順:**
1. `/user/diary`に遷移
2. ページが完全にロードされるまで待機

**期待される結果:**
- ページがエラーなく正常にロード
- URLが`/user/diary`
- ナビゲーションバーに「テスト用ユーザー」ボタンが表示
- 左上に紫色の作成ボタンが表示
- 日記一覧セクションが表示
- 上部にページネーションコントロールが表示

#### 1.2 日記カードの表示確認
**手順:**
1. `/user/diary`に遷移
2. 一覧内の日記カードを確認

**期待される結果:**
- 最低1枚の日記カードが表示（シードデータから5件）
- 各カードに以下が表示:
  - 日付ボックス上部に月番号
  - 日付ボックス下部に日番号
  - 翻訳コンテンツのテキスト（英語）
  - 母語コンテンツのテキスト（日本語）
  - 音声プレーヤーまたは「音声変換中...」メッセージ
- カードがレスポンシブグリッドで配置（デスクトップで3列）
- カードが作成日降順で表示（最新が最初）

#### 1.3 レスポンシブレイアウトの確認
**手順:**
1. デスクトップビューポート（1920x1080）で`/user/diary`をロード
2. グリッドレイアウトが3列になっていることを確認
3. タブレットビューポート（768x1024）にリサイズ
4. グリッドレイアウトが2列になっていることを確認
5. モバイルビューポート（375x667）にリサイズ
6. グリッドレイアウトが1列になっていることを確認

**期待される結果:**
- デスクトップ: 3列グリッドレイアウト（`lg:w-1/3`）
- タブレット: 2列グリッドレイアウト（`md:w-1/2`）
- モバイル: 1列レイアウト（`w-full`）
- すべてのコンテンツが読みやすく適切にフォーマット
- 横スクロール不要

ページネーションやエッジケースのテストは以下のような感じです。

#### 3.1 ページネーションコントロールの表示
**手順:**
1. テストデータベースに50件以上の日記エントリーを用意
2. `/user/diary`に遷移
3. 一覧上部のページネーションコントロールを見つける

**期待される結果:**
- 50件以上のエントリーがある場合、ページネーションコントロールが表示
- 現在のページ番号がハイライト
- 「次へ」「前へ」リンクが表示（該当する場合）
- ページ番号がクリック可能

#### 3.2 次ページへの遷移
**手順:**
1. データベースに51件以上の日記エントリーがある状態で`/user/diary`に遷移
2. 「次へ」リンクまたはページ2のリンクをクリック

**期待される結果:**
- URLがページネーションパラメータを含むように更新（例: `/user/diary?page=2`）
- 異なる日記エントリーのセットでページがロード
- 表示される日記エントリーがページ1と異なる
- ページネーションコントロールが現在のページを反映
- 「前へ」リンクがアクティブに

#### 6.1 日記エントリーがない場合の表示
**手順:**
1. テストユーザーのすべての日記エントリーをクリア
2. `/user/diary`に遷移

**期待される結果:**
- ページがエラーなくロード
- 作成ボタンが表示され機能する
- 空の一覧セクションが表示
- 日記カードが表示されない
- ページネーションコントロールが表示されない
- エラーメッセージが表示されない

#### 6.2 空状態から最初の日記作成
**手順:**
1. エントリーがない状態で`/user/diary`に遷移
2. 作成ボタンをクリック
3. 日記作成プロセスを完了
4. `/user/diary`に戻る

**期待される結果:**
- 空状態から作成ページへのナビゲーションが機能
- 日記作成後、一覧に新しいエントリーが表示
- 日記カードがすべての期待されるフィールドを表示
- 音声生成が自動的に開始

#### 11.1 存在しない日記へのナビゲーション処理
**手順:**
1. `/user/diary/99999`（存在しないID）に遷移

**期待される結果:**
- 404エラーページまたは適切なエラーメッセージ
- ユーザーが一覧に戻ることが可能
- アプリケーションクラッシュなし
- エラーが適切にログ記録

パフォーマンス関連のテストもあります。

#### 13.1 ページロードパフォーマンス
**手順:**
1. 50件の日記エントリーがある状態で`/user/diary`に遷移
2. ブラウザDevToolsでページロード時間を測定

**期待される結果:**
- 初期ページロードが2秒以内に完了
- Livewireコンポーネントが迅速に初期化
- 画像と音声参照が非同期でロード
- ブロッキングリソースなし

#### 13.2 ページネーションパフォーマンス
**手順:**
1. 50件以上のエントリーがある複数ページ間をナビゲート
2. ページ遷移時間を測定

**期待される結果:**
- ページ遷移が1秒以内に完了
- ページ間のスムーズなナビゲーション
- 目に見える遅延やラグなし
- フラッシュなしでコンテンツが更新

ユーザー認証関連も。

#### 14.2 ユーザー固有データ表示確認
**手順:**
1. テストユーザー（test@example.com）としてログイン
2. `/user/diary`に遷移
3. テストユーザーの日記のみが表示されることを確認

**期待される結果:**
- 認証済みユーザーに属する日記のみ表示
- 日記数がテストユーザーのエントリー数と一致（シードから5件）
- 他のユーザーのデータが表示されない
- データ分離が維持

以下は表示関連のテストですが、先ほどのページネーションのテストと少し被っている部分もあります。

#### 15.1 単一日記エントリーの表示
**手順:**
1. テストユーザーがちょうど1件の日記エントリーを持つように設定
2. `/user/diary`に遷移

**期待される結果:**
- 単一の日記カードが正しく表示
- ページネーションコントロール非表示
- 作成ボタンが引き続き機能
- レイアウトが適切な構造を維持

#### 15.2 ちょうど50件の日記エントリー（ページネーション境界）
**手順:**
1. テストユーザーがちょうど50件の日記エントリーを持つように設定
2. `/user/diary`に遷移

**期待される結果:**
- すべての50件のエントリーがページ1に表示
- ページネーションコントロール非表示
- ページが効率的にロード
- すべてのカードが正しくレンダリング

#### 15.3 51件の日記エントリー（ページネーショントリガー）
**手順:**
1. テストユーザーがちょうど51件の日記エントリーを持つように設定
2. `/user/diary`に遷移

**期待される結果:**
- 最初の50件のエントリーがページ1に表示
- ページネーションコントロールが表示
- ページ2のリンクが利用可能
- ページ2をクリックすると51件目のエントリーが表示

#### 15.4 非常に長い日記コンテンツ
**手順:**
1. 500文字の母語コンテンツで日記を作成
2. 500文字の翻訳コンテンツで日記を作成
3. `/user/diary`に遷移

**期待される結果:**
- コンテンツが300文字で適切に省略
- レイアウト崩れなし
- カードが一貫した高さを維持
- 詳細ページで完全なコンテンツが利用可能

#### 15.5 コンテンツ内の特殊文字
**手順:**
1. 日本語特殊文字（々、〜など）で日記を作成
2. 絵文字文字で日記を作成
3. HTML特殊文字（<、>、&など）で日記を作成
4. `/user/diary`に遷移

**期待される結果:**
- すべての特殊文字が正しく表示
- HTMLインジェクションやXSS脆弱性なし
- 文字が適切にエンコード
- レイアウトやレンダリング問題なし

基本的な画面表示からパフォーマンス測定、エッジケースまで網羅的にカバーされています。ページネーションや表示関連ではもう少しケースをまとめられるような気がするので、作成されたテストプランは人間の確認が現時点では必要そうです。

generator・healerでE2Eテストを作成

テストプランができたので、こちらを元にテストコードを作成します。提案されたテストケース数が多いため、今回は一部のテストのみを指定して以下のように生成を依頼しました。

このテストプランをもとに、2.1 日記一覧の表示 のテストを作成してください

@agent-playwright-test-generatorとエージェントを明示しなくても、文脈から判断して自動でテスト作成用エージェントを起動してくれました。

テスト作成時のスクリーンショット

テスト作成完了後、テストの動作確認を依頼したところエラーが発生しました。すると自動でplaywright-test-healerを起動して修正してくれます。

エラー修正時のスクリーンショット

エラーの原因は、複数のLink要素が画面上に存在しており、一意に指定できなかったためでした。今回はfirst()を追加してエラーが修正されました。

  // 修正前
      await expect(page.getByRole('main').getByRole('link')).toBeVisible();

  // 修正後
      await expect(page.getByRole('main').getByRole('link').first()).toBeVisible();

このように検証対象の要素が一意に特定しにくいHTMLとなっていると、テスト作成に時間がかかったり、セレクタ指定が冗長になるということがあります。

そのため、HTMLにdata-testid属性を付与したり、aria-labelを付与してgetByRole()で取得しやすくしておくと、よりスムーズにテスト作成ができるようになると思います。

Playwrightの推奨ロケーターは複数ありますので、ドキュメントをご参照ください。

実際に作成されたテストコードと、気になった点

修正も完了し、実際に作成されたテストコードが以下となります。

バリデーション関連のテスト

  test('Empty Form Submission', async ({ page }) => {
    // 1. Login with test@example.com / password
    await page.goto('http://127.0.0.1:8000/login');
    await page.getByRole('textbox', { name: 'メールアドレス' }).fill('test@example.com');
    await page.getByRole('textbox', { name: 'パスワード' }).fill('password');
    await page.getByRole('button', { name: 'ログイン' }).click();

    // 2. Navigate to diary creation page (/user/diary/create)
    await page.goto('http://127.0.0.1:8000/user/diary/create');

    // 3. Leave the textarea empty (do not enter any text)
    // (No action needed - textarea is already empty)

    // 4. Click "次へ！" (Next!) button
    await page.getByRole('button', { name: '次へ！' }).click();

    // Verify validation error is displayed
    await expect(page.getByText('母語のテキストは必ず指定してください。')).toBeVisible();

    // Verify user remains on Step 1 (did not proceed to Step 2)
    await expect(page.getByRole('heading', { name: 'Step 1: まずは日本語で書いてみよう' })).toBeVisible();
  });

日記一覧画面表示のテスト

  test('日記一覧の表示と基本機能', async ({ page }) => {
    // ログインページにアクセス
    await page.goto('http://127.0.0.1:8000/login');
    
    // メールアドレスを入力
    await page.getByRole('textbox', { name: 'メールアドレス' }).fill('test@example.com');
    
    // パスワードを入力
    await page.getByRole('textbox', { name: 'パスワード' }).fill('password');
    
    // ログインボタンをクリック
    await page.getByRole('button', { name: 'ログイン' }).click();
    
    // ログイン後、ダッシュボード (/user/diary) にアクセスされることを確認
    await expect(page).toHaveURL('http://127.0.0.1:8000/user/diary');
    
    // ナビゲーションバーにユーザー名ボタンが表示されることを確認
    await expect(page.getByRole('button', { name: 'テスト用ユーザー' })).toBeVisible();
    
    // 新規作成ボタン（ペンアイコン）が表示されることを確認
    await expect(page.getByRole('main').getByRole('link').first()).toBeVisible();
    
    // 日記エントリーの英訳された内容（見出し）が表示されることを確認
    await expect(page.getByText('The weather was really nice today. I took a walk in the park this morning and saw beautiful cherry blossoms. I was happy to feel the arrival of spring.').first()).toBeVisible();

    // 日記エントリーの日本語原文が表示されることを確認
    await expect(page.getByText('今日はとても良い天気でした。朝から公園を散歩して、美しい桜を見ました。春の訪れを感じることができて嬉しかったです。').first()).toBeVisible();

    // 日付（月）が表示されることを確認
    await expect(page.getByText('10').first()).toBeVisible();

    // 日付（日）が表示されることを確認
    await expect(page.getByText('18').first()).toBeVisible();
    
    // 任意の日記カードをクリック
    await page.getByRole('heading', { name: 'The weather was really nice' }).first().click();
    
    // 日記詳細ページに遷移することを確認（URL に /user/diary/{id} が含まれる）
    await expect(page.url()).toMatch(/\/user\/diary\/\d+/);
    
    // 詳細ページに年が表示されることを確認
    await expect(page.getByText('2025')).toBeVisible();
    
    // 詳細ページに日付が表示されることを確認
    await expect(page.getByText('10-18')).toBeVisible();
    
    // 日記一覧に戻るボタンが表示されることを確認
    await expect(page.getByRole('link', { name: '日記一覧' })).toBeVisible();
    
    // 日記一覧に戻るボタンをクリック
    await page.getByRole('link', { name: '日記一覧' }).click();
    
    // ダッシュボードに戻ることを確認
    await expect(page).toHaveURL('http://127.0.0.1:8000/user/diary');
  });

作成されたテストケースは各要素を細かくアサートしてくれており、コメントも十分なほど付いているのでコードを詳しく読まなくても何をテストしているのかがよくわかります。

これらをほぼ自動で作ってくれるという点でとても凄いAgents機能ですが、一方、現時点で気になった点もありましたので以下にまとめます。

・テストごとにログイン処理のコードが記述されている

バリデーションテスト・一覧表示確認のテストそれぞれにログイン処理のコードが含まれていました。ログイン後の画面で実施するテストであれば、テストに直接関係しないログイン動作は省略するのが理想的です。

テストプラン作成〜テストコード作成の流れの中では、Playwright側から「ログイン動作をまとめる」という提案は特にありませんでした。本来、認証関連はseed.spec.tsなどにまとめるべきなので、プラン作成前の段階であらかじめ方針を決めておく必要がありそうです。

・テストのたびに異なる値を固定値でチェックしている

日記カードの表示確認テストでは、日記タイトルや内容を固定の文字列で比較して存在確認を行うコードになっていました。しかし、これらの値は実行のたびに変化する可能性があるため、固定値での比較は望ましくありません。

他のテスト項目でも同様に、固定値でチェックする形になっている箇所が複数あり気になりました。こちらもあらかじめルールを設けておく必要がありそうです。

・外部APIのモック化

日記の新規作成時には、AI翻訳のため外部APIとの通信が発生する仕組みです。テスト実行のたびにこのAPI通信が発生し課金も伴うため、できればテスト環境ではモック化を検討して欲しかったです。

この点も、プラン作成前に「外部通信をどう扱うか」を明確にしておく必要がありそうです。

まとめ

今回はClaude Codeへの指示文もシンプルで、ほぼAI任せの状態で作成したことを考えると、事前の準備次第ではもっと精度の高いテストが作成できると思います。

このAgents機能はリリースされてから間もないため、今後どんどんアップデートされることを踏まえると、近いうちに人間不在でのE2Eテスト作成〜実行が現実味を帯びてきたなと感じます。

DB::beginTransactionとDB::transaction

Thu, 23 Oct 2025 09:15:17 +0900

アプリで使用しているデータベースの整合性を保つために、トランザクションのデータベース関数があります。Laravelでは、現時点で２通りの方法があります。Laravelのバージョン12.32.0において、DB::afterRollBackが登場して、どちらとも機能的に同等になりました。

トランザクション

トランザクションを簡単に説明すると、例えば以下のように複数のデータベース文を実行するとき、

DB::table('points')->insert(['member_id' => 1, 'point' => 1000]);
DB::table('points')->insert(['member_id' => 1, 'point' => 2000]);

最初のデータベース文が成功して、２番目のデータベース文が何等かの理由で失敗したときに、成功したものだけを残すのでなく、両方と何も起こらなかった状態に戻す機能です。

つまり、この２つデータベース文をあたかも１つのデータベース文のように扱い、両方が成功するならコミットとし、失敗が起こるならロールバックします。上の例では、成功なら3000ポイント追加され失敗したならたとえ１つが成功しても0ポイントの追加となります。

DB::beginTransaction

トランザクションをLaravelで実行するには、以下のようにDB::beginTransactionを使います。

DB::beginTransaction();

try {
    DB::table('points')->insert(['member_id' => 1, 'point' => 1000]);
    DB::table('points')->insert(['member_id' => 1, 'point' => 2000]);

    DB::commit();

    echo "ポイント追加成功しました。";
} catch (\Exception $event) {
    DB::rollBack();

    echo "ポイント追加に失敗しました。";
    echo $event->getMessage(); // エラーを表示
}

トランザクションと対象となるデータベース文は、try,catchに入れて、成功ならDB::commitで変更を保存し、エラーがあるなら（例外が発生）、DB::rollbackですべての変更を戻します。DB::endTransactionというものはないのでブロックで囲まれてなく変な感じですが、問題はありません。DB::beginTransactionをtryの中の最初の文としても変わりません。

DB::transaction

先の例では、いちいちコミットとロールバック、それぞれDB::commitとDB::rollbackを指定する必要がありますが、DB::transactionを使い対象のデータベース文を以下のようにクロージャのなかに入れるなら、結構すっきりします。

DB::transaction(function () {
    DB::table('points')->insert(['member_id' => 1, 'point' => 1000]);
    DB::table('points')->insert(['member_id' => 1, 'point' => 2000]);
})

以下のようにデータを変数で渡すことも可能です。

$data = [
    ['member_id' => 1, 'point' => 1000],
    ['member_id' => 1, 'point' => 2000]
];

DB::transaction(function () use($data) {
    DB::table('points')->insert($data[0]);
    DB::table('points')->insert($data[1]);
})

また、DB::beginTransactionのように、コミットとロールバックの後に必要なプログラム文を追加も以下のように可能です。

$data = [
    ['member_id' => 1, 'point' => 1000],
    ['member_id' => 1, 'point' => 2000]
];

DB::transaction(function () use($data) {
    DB::afterCommit(function() {
        echo "ポイント追加成功しました。";
    });

    DB::afterRollBack(function () {
        echo "ポイント追加に失敗しました。";
    });

    DB::table('points')->insert($data[0]);
    DB::table('points')->insert($data[1]);
})

注意する必要があるのは、対象のデータベース文は、DB::afterCommitとDB::afterRollBackの後に必ず置くことです。また、DB::afterRollBackは、Laravelのバージョン12.32.0においての登場なので、それより前のバージョンでは使えません。

最後に、DB::beginTransactionの例のようにエラーをキャッチしたいなら、同様にtry,catchを使います。

$data = [
    ['member_id' => 1, 'point' => 1000],
    ['member_id' => 1, 'point' => 2000]
];

try {
    DB::transaction(function () use($data) {
        DB::afterCommit(function() {
            echo "ポイント追加成功しました。";
        });

        DB::afterRollBack(function () {
            echo "ポイント追加に失敗しました。";
        });

        DB::table('points')->insert($data[0]);
        DB::table('points')->insert($data[1]);
    });
} catch (\Exception $event) {
    echo $event->getMessage();
}

PlaywrightでE2Eテストを自動化（３）codegenでコード生成

Thu, 02 Oct 2025 07:37:05 +0900

Playwright、３記事目の今回はcodegenを使ってテストコードを生成します。codegenは、ブラウザ上での実際の操作を記録し、それをPlaywrightのテストコードに変換してくれる便利な機能です。VSCodeの拡張機能「Playwright Test for VSCode」も存在していますが、今回はシンプルにPlaywrightの機能のみを使用して作成します。

codegenでテストを作成する流れ

codegenでテストを作成する、大まかな流れは以下のようになっています。

codegenでブラウザを操作してテストコードを生成
生成されたコードをVScodeなどのエディタにコピー
テストコードの修正

前回の記事でも使用したLaravelプロジェクトを使って、ログイン〜ログアウトをこの流れでテストコードにしてゆきます。

codegenで動作を記録

Playwrightはすでにインストール済みの状態から始めます。インストールがまだの方はセットアップの記事をご確認ください。

以下のコマンドでcodegenを起動します。コマンドの最後に対象のURLを書いておくと、URLへ遷移した状態で始めることができます。この例ではローカルのポート8000を使用していますが、実際の環境に合わせてURLを変更ください。

$ npx playwright codegen http://127.0.0.1:8000

コマンドを実行すると、ブラウザとPlaywrightインスペクターウィンドウが立ち上がりました。

この状態から実際にブラウザを操作してテスト対象の動作を行うことで、テストコードが生成されてゆきます。例えば、メールアドレス入力欄に"test@example.com"と入力してみると、インスペクターの方にもコードが出力されます。

ですが、想像していたより多くコードが生成されたようなので内容を確認してみます。以下が実際のコードです。

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

test('test', async ({ page }) => {
  await page.goto('http://127.0.0.1:8000/login');
  await page.getByRole('textbox', { name: 'メールアドレス' }).click();
  await page.getByRole('textbox', { name: 'メールアドレス' }).press('Eisu');
  await page.getByRole('textbox', { name: 'メールアドレス' }).fill('test@example.com');
});

「メールアドレスを入力」という動作だけのつもりだったのですが、入力欄をクリックする動作やキーボードの英数キーをクリックした動作までコードに反映されてしまっているようです。インスペクタ上ではコードを削除・修正はできないので、こちらはエディタにコピーしてから修正が必要になります。

肝心のメールアドレス入力は、最後の行にawait page.getByRole(’textbox’, { name: ‘メールアドレス’ }).fill(’test@example.com’);として、ちゃんと生成されていますね。

codegenでアサートを追加

テストジェネレーターで追加できるアサーションは以下の３種類となっています。

左端の目のアイコン assert visibility：要素がページ上で可視状態であることを確認
中央"ab"のアイコンassert text：要素が指定されたテキストコンテンツを含んでいることを確認
右端テキストボックスアイコンassert value：入力要素が特定の値を持っていることを確認

今回のテストでは、assert text・assert visibilityの２つを使用します。まずはassert textで、「ログイン成功後にアカウント名が表示されていること」のアサーションを作成します。

①"ab"アイコンをクリックし、②確認対象の要素（アカウント名）をクリックします。すると以下のように入力ボックスが表示されるので、テスト用の文字列を変更したい場合はこちらで修正が可能です。問題なければ③のチェックマークをクリック。

assert textでは、以下のようにtoContainText()を使用したアサーションが生成されます。

await expect(page.getByRole('button')).toContainText('テスト用ユーザー');

続いてassert visibilityで、「ログアウト後に"ログインボタン"が表示されていること」のアサーションを作成します。

①目のアイコンをクリックし、②確認対象の要素（ログインボタン）をクリックします。

assert visibilityでは、以下のようにtoBeVisible()を使用したアサーションが作成されます。

await expect(page.getByRole('button', { name: 'ログイン' })).toBeVisible();

本当は「遷移後のURLが期待通りであるか」のアサーションも作成したかったのですが、現状テストジェネレーターにはURLを直接アサートするための機能はありませんでした。

基本的に、ページ上の要素（ボタン、テキスト、入力欄など）に対して「表示されているか」「特定のテキストを含んでいるか」などの検証のみとなっているようなので、URLのアサートを追加したい場合は手動で追記する必要があります。

テストコードの作成が完了したら

テストコードをひととおり作成したら、インスペクタの赤丸ボタンをクリックして記録を停止させます。コピーボタンでコードをコピーしたら、あとはエディタに貼り付けて修正を行います。

不要なコードを削除

codegenが生成してくれたコードは以下の通りです。

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

test('test', async ({ page }) => {
  await page.goto('http://127.0.0.1:8000/login');
  await page.getByRole('textbox', { name: 'メールアドレス' }).click();
  await page.getByRole('textbox', { name: 'メールアドレス' }).press('Eisu');
  await page.getByRole('textbox', { name: 'メールアドレス' }).fill('test@example.com');
  await page.getByRole('textbox', { name: 'メールアドレス' }).press('Tab');
  await page.getByRole('textbox', { name: 'パスワード' }).fill('password');
  await page.getByRole('button', { name: 'ログイン' }).click();
  await expect(page.getByRole('button')).toContainText('テスト用ユーザー');
  await page.getByRole('button', { name: 'テスト用ユーザー' }).click();
  await page.getByText('ログアウト').click();
  await expect(page.getByRole('button', { name: 'ログイン' })).toBeVisible();
});

先述の通りキーボードを押した時の動作などもコードになってしまっているので、これらの不要な行を削除します。

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

test('test', async ({ page }) => {
  await page.goto('http://127.0.0.1:8000/login');

  //ログイン動作
  await page.getByRole('textbox', { name: 'メールアドレス' }).fill('test@example.com');
  await page.getByRole('textbox', { name: 'パスワード' }).fill('password');
  await page.getByRole('button', { name: 'ログイン' }).click();

  //ログイン後のアサーション
  await expect(page.getByRole('button')).toContainText('テスト用ユーザー');
  
  //ログアウト動作
  await page.getByRole('button', { name: 'テスト用ユーザー' }).click();
  await page.getByText('ログアウト').click();
  
  //ログアウト後のアサーション
  await expect(page.getByRole('button', { name: 'ログイン' })).toBeVisible();
});

これでスッキリしました。まだここからBaseURLを使用する形に修正したり、URLアサーションの追加などを適宜行う必要はありますが、叩き台を作成してくれるので使い慣れればテストの作成時間を短縮できそうです。

自分で書いたコードとcodegenが生成したテストコードの違い

今回codegenが生成してくれたコードを見て、前回私が手動で作成したコードとの違いの中で気になったのはロケータの選定です。

自作のコードでは、getByLabel()を使用しました。

await page.getByLabel('メールアドレス').fill('test@example.com');

一方codegenは、getByRole()を使用しています。

await page.getByRole('textbox', { name: 'メールアドレス' }).fill('test@example.com');

getByLabel()は、getByRole()に比べてコードが簡潔に書けます。またラベル要素を指定することで「フォーム要素のテストである」という意図がわかりやすい、といったメリットがあります。

getByRole()は、こちらも「“メールアドレス"というテキストボックスが対象」という意図がわかりやすいです。getByLabel()との一番の違いは、フォーム要素に限らず様々な要素指定に使える汎用性が高いロケーターである、という点です。

どちらもPlaywrightの推奨ロケータですが、今後codegenに限らずAIでE2Eテストを作成する機会が増えることになるかと思いますので、手動作成とAIが生成したコードの差異を出さないためにも生成コードに寄せていったほうがいいのかな、と思いました。

MCPサーバーを作ろう

Fri, 26 Sep 2025 08:09:51 +0900

先月からClaude Codeを使い始めました。コンソールでの対話形式に関わらずその利便さと技術の進化に驚嘆して、さらに最近のLaravel Boostの登場で、LaravelのエコシステムにおいてMCPサーバーの開発対応がすでになされていることにさらに驚嘆。MCPサーバーは、ClaudeのようなAIエージェントに道具（ツール）を提供するインターフェースです。と言っても、具体的な例がないとわかりづらいので、早速MCPサーバーを作成してみることにします。

通貨換算のMCPサーバー

Laravelのマニュアルでは天気や温度を尋ねることができるサンプルでMCPサーバーを説明していますが、無料の為替レートのapiを見つけたので、ここではそれをもとに、Claude Codeにおいて、

> １ドルを円に換算してください                                                                                                   

● 1ドルは148.44円です。

このようなことを可能とさせるMCPサーバーを開発します。

いつものようにブラウザで対話するアプリを作成するのではなく、MCPサーバーのLaravelアプリを開発して、そのアプリのもとでClaude Codeを立ち上げ上の対話ができるように設定します。

MCPサーバーの開発

開発を始める前にまず必要なのは、laravel/mcpのパッケージのインストール

$ composer require laravel/mcp

そして、artisan makeでサーバーのクラスを作成します。

$ php artisan make:mcp-server CurrencyConversionServer

そして、次はそこで使用されるツールのクラスを作成。

$ php artisan make:mcp-tool CurrencyConversionTool

まずツールのクラスから見ていきます。

app/mcp/Servers/CurrencyConversionServer.php

namespace App\Mcp\Tools;

use Laravel\Mcp\Request;
use Laravel\Mcp\Response;
use Laravel\Mcp\Server\Tool;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Facades\Http;
use Illuminate\JsonSchema\JsonSchema;

class CurrencyConversionTool extends Tool
{
    /**
     * The tool's description.
     */
    protected string $description = 'このツールは、異なる通貨間の換算を行います。';

    /**
     * Handle the tool request.
     */
    public function handle(Request $request): Response
    {
        $validated = $request->validate([
            'from' => 'required|string|in:USD,JPY',
            'to' => 'required|string|in:USD,JPY',
            'amount' => 'required|numeric|min:0',
        ], [
            'from.in' => 'サポートされていない通貨です。USDまたはJPYを使用してください。',
            'to.in'   => 'サポートされていない通貨です。USDまたはJPYを使用してください。',
        ]);

       // TODO: 後に外部のAPIを使用して為替レートを取得して通貨換算を行う

        return Response::text('100');　// 今は固定
    }

    /**
     * Get the tool's input schema.
     *
     * @return array<string, \Illuminate\JsonSchema\JsonSchema>
     */
    public function schema(JsonSchema $schema): array
    {
        return [
            'from' => $schema->string()->description('換算元の通貨, "USD".')->required(),
            'to' => $schema->string()->description('換算先の通貨, "JPY".')->required(),
            'amount' => $schema->number()->description('換算する通貨の金額.')->required()
        ];
    }
}

上のクラスでは、handle()とschema()のメソッドがありますが、handle()は、コントローラのように入力を受け取るRequestのクラスがあり、入力バリデーションと同様なvalidate()も実行できます。schema()はAIがこのツールを利用してどのような値を渡す必要があるか理解するためのメソッドです。

AIエージェントから受け取る入力の値は、schema()で説明しているようにfrom, to, amountと３つあり、それぞれ換算元の通貨、換算先の通貨、換算する通貨の金額からなります。例えば、それぞれ、USD, JPY, 1とかの値を受け取ります。ドル、円とかになっていないことに注意、それは頭が良いAIがドルをUSDに円をJPYとしてツールに渡します。

後に外部のAPIを利用して為替のレートを取得して換算を行うコードをいれますが、今はいつも100の値を返すようにします。

上で作成したツールは以下のサーバーのクラスに登録します。

app/mcp/Servers/CurrencyConversionServer.php

namespace App\Mcp\Servers;

use App\Mcp\Tools\CurrencyConversionTool;
use Laravel\Mcp\Server;

class CurrencyConversionServer extends Server
{
    /**
     * The MCP server's name.
     */
    protected string $name = '通貨換算サーバー';

    /**
     * The MCP server's version.
     */
    protected string $version = '0.0.1';

    /**
     * The MCP server's instructions for the LLM.
     */
    protected string $instructions = 'Instructions describing how to use the server and its features.';

    /**
     * The tools registered with this MCP server.
     *
     * @var array<int, class-string<\Laravel\Mcp\Server\Tool>>
     */
    protected array $tools = [
        CurrencyConversionTool::class,
    ];

    /**
     * The resources registered with this MCP server.
     *
     * @var array<int, class-string<\Laravel\Mcp\Server\Resource>>
     */
    protected array $resources = [
        //
    ];

    /**
     * The prompts registered with this MCP server.
     *
     * @var array<int, class-string<\Laravel\Mcp\Server\Prompt>>
     */
    protected array $prompts = [
        //
    ];
}

そしてそれを、今度は上のサーバーとルートに登録します。

routes/ai.php

use App\Mcp\Servers\CurrencyConversionServer;

use Laravel\Mcp\Facades\Mcp;

Mcp::local('currency-conversion', CurrencyConversionServer::class);

上の設定ではMcp::localを使用して、php artisan mcp:startで立ち上げたサーバーでAIエージェントからのアクセスを可能とします。他にもMcp::webとしてウェブつまりhttpsでもアクセスが可能です。

最後に、AIエージェントにおいてMCPサーバーを登録します。

$ claude mcp add -s project currency-conversion php artisan mcp:start currency-conversion

この実行は、以下のファイルを作成します。

.mcp.json

{
  "mcpServers": {
    "currency-conversion": {
      "type": "stdio",
      "command": "php",
      "args": [
        "artisan",
        "mcp:start",
        "currency-conversion"
      ],
      "env": {}
    }
  }
}

動作確認

さて、これでコンソールでClaude Codeを立ち上げて、動作確認します。立ち上げると、

New MCP server found in .mcp.json: currency-conversion 

│ MCP servers may execute code or access system resources. All tool calls require approval. Learn more in the MCP
│ documentation (https://docs.claude.com/s/claude-code-mcp).
│                                                                                               
│ ❯ 1. Use this and all future MCP servers in this project                                                            
│   2. Use this MCP server                                                                                     
│   3. Continue without using this MCP server

と問われます。新規のMCPサーバーを発見したということで、使用するかどうか聞いています。もちろんなので、そのままEnterで進みます。これで次回からは問われません。

その後、MCPサーバーが登録されているか確認します。

> /mcp

Manage MCP servers                                                                                 
❯ 1. currency-conversion            ✔ connected · Enter to view details

MCPサーバーに接続されていますね。

さて質問してみましょう。

> １ドルを円に換算してください

● currency-conversion - currency-conversion-tool (MCP)(from: "USD", to: "JPY", amount: 1)
  ⎿  100

● 1ドルは100円です。

AIがドルをUSDに円をJPYに変えてツールを使用していることわかります。

こちらの質問はどうかな。バリデーションで米ドルと円のみの対応に限定しているのでエラーとなるはずです

> １ドルをユーロに換算してください

● currency-conversion - currency-conversion-tool (MCP)(from: "USD", to: "EUR", amount: 1)
  ⎿  Error: サポートされていない通貨です。USDまたはJPYを使用してください。

● このMCP通貨変換ツールは、現在USDとJPYの間の換算のみサポートしているようです。USD（ドル）からEUR（ユーロ）への変換はサポ
  ートされていません。

期待通りエラーとなりましたね。

為替レートを取得

動作確認したところで、実際に為替を取得して通貨換算を行うコードをいれます。

namespace App\Mcp\Tools;

use Laravel\Mcp\Request;
use Laravel\Mcp\Response;
use Laravel\Mcp\Server\Tool;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Facades\Http;
use Illuminate\JsonSchema\JsonSchema;

class CurrencyConversionTool extends Tool
{
    /**
     * The tool's description.
     */
    protected string $description = 'このツールは、異なる通貨間の換算を行います。';

    /**
     * Handle the tool request.
     */
    public function handle(Request $request): Response
    {
        $validated = $request->validate([
            'from'   => 'required|string|in:USD,JPY',
            'to'     => 'required|string|in:USD,JPY',
            'amount' => 'required|numeric|min:0',
        ], [
            'from.in' => 'サポートされていない通貨です。USDまたはJPYを使用してください。',
            'to.in'   => 'サポートされていない通貨です。USDまたはJPYを使用してください。',
        ]);

        try {
            $response = Http::get('https://api.frankfurter.dev/v1/latest', [
                'amount' => $validated['amount'],
                'base' => strtoupper($validated['from']),
                'symbols' => strtoupper($validated['to'])
            ]);

            if (!$response->successful()) {
                return Response::error('現在、換算サービスが利用できません。');
            }

            $data = $response->json();

            if (!isset($data['rates'][strtoupper($validated['to'])])) {
                return Response::error('通貨が見つかりません');
            }

            $converted = $data['rates'][strtoupper($validated['to'])];

            return Response::text((string) $converted);

        } catch (\Exception $e) {
            return Response::error('通貨変換に失敗しました');
        }
    }
...

AIエージェントから受けとった入力は、https://frankfurter.devのサイトのAPIを利用します。上のコードは基本的に以下のような実行となり、

https://api.frankfurter.dev/v1/latest?amount=1&base=USD&amp;symbols=JPY

レスと返ってくるjsonから必要な値を取り出します。

{
　　"amount":1.0,
　　"base":"USD",
　　"date":"2025-09-24",
　　"rates":{"JPY":148.44}
}

これでMCPサーバー作成のコーディングは完了です。テストしてみましょう。

> 1000円をドルに換算してください

● currency-conversion - currency-conversion-tool (MCP)(from: "JPY", to: "USD", amount: 1000)
  ⎿  6.72

● 1000円は約6.72ドルです。

ばっちりです。

最後に

今回のMCPサーバーの開発を始める前に、もしかしたらツールを開発するまでもなくAIの方で勝手に情報を取得してくるのでは、という疑問があり尋ねてみたら、

> １ドルを円に換算してください

● 為替レートは常に変動しているため、現在の正確な換算レートを確認する必要があります。

● Web Search("USD JPY exchange rate today 2025")
  ⎿  Did 1 search in 16s

● 現在（2025年9月24日時点）の為替レートによると、1ドル = 約147-148円です。

  具体的には：
  - 147.78円（一部のソースより）
  - 148.71円（別のソースより）
  - 146.58円（その他のソースより）

  為替レートはリアルタイムで変動しているため、各金融機関や為替サイトで若干異なる数値が表示されますが、現在は1ドル =
  約147-148円の範囲で取引されています。

どこかのウェブで検索してきて取得したみたいです。

もちろん、MCPサーバーを作成する方が、正確でいつも安定な答えを取得できるのは確かです。

PlaywrightでE2Eテストを自動化（２）ログイン・ログアウト

Sun, 31 Aug 2025 01:30:21 +0900

前回の記事で、Playwrightのインストールと動作確認までを行いました。さっそくテストコードの自動生成機能を使って簡単にテストを作成したいところですが、現時点ではまだ生成されたコードをそのまま使うというよりも、人間が確認・修正する場合も多いと思います。

そこで今回は、シンプルなログイン・ログアウトのテストを使ってPlaywrightの基本的なテストの書き方をご紹介します。

テスト対象

Laravelプロジェクトの以下のようなログイン・ログアウト画面がテスト対象です。

ログイン画面はこのようなUIです。

テストでは、メールアドレス・パスワードを入力し、ログインボタンをクリックすると http://127.0.0.1:8000/user/diaryへ遷移することを確認します。

ログアウトは、このようなドロップダウンの要素になっています。

ユーザー名をクリックするとドロップダウンが開きます。テストでは、ドロップダウンの中にある「ログアウト」をクリックし、ログアウトが成功してhttp://127.0.0.1:8000/loginへ遷移する、という一連の動作をテストします。

ログイン・ログアウトのテストコード

まず、ログイン・ログアウトのテストコード全体を見てみましょう。これは.tsのTypeScriptであることに注意してください。

e2e/auth.spec.ts

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

test.describe('認証テスト', () => {
    test('ユーザーログイン', async ({ page }: { page: Page }) => {
        await page.goto('/login');

        await page.getByLabel('メールアドレス').fill('test@example.com');
        await page.getByLabel('パスワード').fill('password');
        await page.getByRole('button', { name: 'ログイン' }).click();

        // ログイン後の確認
        await expect(page).toHaveURL('/user/diary');

        // ユーザー名が表示されていることを確認
        await expect(page.getByRole('button', { name: 'テスト用ユーザー' })).toBeVisible();
    });

    test('ユーザーログアウト', async ({ page }: { page: Page }) => {
        // ログイン処理
        await page.goto('/login');

        await page.getByLabel('メールアドレス').fill('test@example.com');
        await page.getByLabel('パスワード').fill('password');
        await page.getByRole('button', { name: 'ログイン' }).click();

        // ログイン後の確認
        await expect(page).toHaveURL('/user/diary');

        // ユーザー名をクリックしてドロップダウンメニューを開く
        await page.getByRole('button', { name: 'テスト用ユーザー' }).click();

        // ログアウトをクリック
        await page.getByRole('button', { name: 'ログアウト' }).click();

        // ログアウト後の確認
        await expect(page).toHaveURL('/login');
        await expect(page.getByRole('button', { name: 'ログイン' })).toBeVisible();
    });
});

実行は以下のコマンドで行います。

$ npx playwright test auth

全体像がわかったところで、上のテストスクリプトにおけるPlaywrightの使い方を解説します。

Playwrightの構文

Playwrightの基本的な構文は、describe（テストをまとめるグループのようなもの）とtest（テストの１つ１つ）で構成されています。

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

test.describe('グループ', () => {
  test('テスト１', async ({ page }) => {
    // ...
  });

  test('テスト２', async ({ page }) => {
    // ...
  });
});

describeは必須ではないので、testだけを使っても問題ありません。

Playwrightのコマンド

次に、今回のテストで使用したPlaywrightのコマンドをご紹介します。

まずは画面遷移から。goto()を使用します。

await page.goto('http://127.0.0.1:8000');

コマンドの最初にあるawaitですが、こちらは処理の完了を待つために必要なものです。Playwrightの多くのコマンドは非同期処理なので、awaitを付けることで処理を待ってから安全に次に進むことができます。

そしてawaitの後ろにあるpageは、ページ操作のためのオブジェクトです。このpageオブジェクトの後にメソッドチェーンでgoto()などの各コマンドを繋ぐ形になっています。

次はフォーム入力です。以下のように「要素の取得」と「動作コマンド」を繋いで記述できます。

await page.getByLabel('メールアドレス').fill('test@example.com');

要素の取得はgetByLabel()というPlaywrightのコマンドを使い、引数に”メールアドレス”というラベルテキストを指定します。

E2Eテストの要素指定には、修正が発生しやすいCSSセレクタやXpathはできるだけ避け、ユーザーが実際に目にする要素を優先して指定することが推奨されており、そのための色々なロケータが用意されています。

そしてfill()に入力したい内容を渡します。

次は、「ログインボタンをクリック」のようなクリック動作です。

await page.getByRole('button', { name: 'ログイン' }).click();

getByRole()というコマンドを使用してまずは要素を取得しています。要素の役割（この場合はbutton）と、nameプロパティには、ラベルや要素のテキスト（この場合は”ログイン”）を渡します。

そして、click()を繋いでボタンをクリックします。

Playwrightのアサーション

次は検証コマンドです。「現在のURLがhttp://127.0.0.1:8000/loginである」ということを確認したい場合には、以下のように記述します。

await expect(page).toHaveURL('http://127.0.0.1:8000/login');

expect()の中に確認したい対象（この例ではpageオブジェクト）を渡し、toHaveURL()を繋いで期待するURLを指定します。

また、ログイン成功後の画面で「”テスト用ユーザー”というテキストを持つボタン要素が画面に表示されている」ということを確認したい場合、以下のように記述します。

await expect(page.getByRole('button', { name: 'テスト用ユーザー' })).toBeVisible();

こちらもexpect()から始まり、getByRole()に対象要素のbuttonと、nameプロパティにユーザー名を渡します。そしてtoBeVisible()を繋いでその要素が表示されているかを確認する、という流れです。

BaseURLを設定

テストで使用するURLは、playwright.config.tsにBaseURLとして指定しておくと便利です。

playwright.config.ts

export default defineConfig({
・・・・・
  use: {
    /* Base URL to use in actions like `await page.goto('/')`. */
    baseURL: 'http://127.0.0.1:8000',
・・・・・

そうすると、goto()やtoHaveURL()で以下のように相対パスで書くことができます。

await page.goto('/login'); // http://127.0.0.1:8000/login にアクセスする

共通処理を関数へ切り出し

ログアウトのテストでは、ユーザーがログインしている状態を作るために、ログイン画面にアクセスしてメールアドレスを入力するなど、一連のログイン動作を記述しています。今回はログイン・ログアウトの２つのテストだけなので必須ではありませんが、「ログイン状態を作るためのコード」を関数として切り出しておくと後々使いまわせますし、テストコードがすっきりします。

e2e/auth.spec.ts

・・・・・
    test('ユーザーログアウト', async ({ page }: { page: Page }) => {
　　　　　// 関数を呼び出す
        await loginUser(page, 'test@example.com', 'password');

        // ここからログアウトのテスト
        ・・・・・
    });
});

// ログイン用関数
async function loginUser(page: Page, email: string, password: string): Promise<void> {
    await page.goto('/login');

    await page.getByLabel('メールアドレス').fill(email);
    await page.getByLabel('パスワード').fill(password);
    await page.getByRole('button', { name: 'ログイン' }).click();

    await page.waitForURL('/user/diary');
}

loginUser()という関数を作成し、そこにログインのためのコードを移しました。そしてログアウトのテストでloginUser()を呼び出しています。

今後共通化したいテストが増えてきたら別ファイルに切り出したり、Playwrightが提供している認証情報保持の機能などを使ってもいいと思います。

次回は、PlaywrightのCodegenを使ってテストコードを作成します。

Viteとバニラjs – Tom Select ドロップダウン

Wed, 20 Aug 2025 08:02:46 +0900

前回のselect2のドロップダウンはjquery依存であったけれど、似たような機能のTom Selectはバニラjsでjqueryの依存がまったくないパッケージです。早速viteでビルドします。

Tom Selectで選択

Tom Selectは、select2と同様にドロップダウンにおいて選択値の検索が可能です。

しかし、select2と比べるとわかりますが、検索窓のための行が追加されるのではなくドロップダウンの最初の行が検索窓となります。そこでBackキーを押すと行が以下のように空になり検索値をタイプできます。

ブレードは以下のようになります。

...
                      <div class="row mb-3">
                            <label for="prefecture-multiple" class="col-md-4 col-form-label text-md-end">都道府県(複数選択)</label>
 
                            <div class="col-md-6">
                                <select id="prefecture-multiple" placeholder="都道府県を選択してください" class="form-select @error('prefecture') is-invalid @enderror" name="prefectures[]" required multiple>
                                    @foreach($prefectures as $prefecture)
                                        <option value="{{ $prefecture }}" {{ in_array($prefecture, old('prefectures', [])) ? 'selected' : '' }}>{{ $prefecture }}</option>
                                    @endforeach
                                </select>
 
                                @error('prefectures')
                                    <span class="invalid-feedback" role="alert">
                                        <strong>{{ $message }}</strong>
                                    </span>
                                @enderror
                            </div>
                        </div>
...
@section('scripts')
<script type="module">
   document.addEventListener('DOMContentLoaded', function() {
        new TomSelect(document.getElementById('prefecture'));
   })
</script>
@endsection

select2のように検索窓を次の行に出すこともTomSelectに渡すオプションで変えることができます。

コードは以下となります。

<script type="module">
   document.addEventListener('DOMContentLoaded', function() {
        new TomSelect(document.getElementById('prefecture'), {
            plugins: ['dropdown_input'], // 検索窓の位置を変える
        });
   })
</script>

他のオプションとしては、空行の選択を許す、 allowEmptyOption: true 全選択値を含む、 maxOptions: null （これがないと、最初50個しか選択値に含まれないので注意を）などがあります。

オプションに関してのドキュメントは以下となります。 https://tom-select.js.org/docs/

Tom Selectで複数を選択

もちろん、select2と同様に複数のアイテムの選択も可能です。

ブレードは、以下のようになります。

...
                      <div class="row mb-3">
                            <label for="prefecture-multiple" class="col-md-4 col-form-label text-md-end">都道府県(複数選択)</label>
 
                            <div class="col-md-6">
                                <select id="prefecture-multiple" placeholder="都道府県を選択してください" class="form-select @error('prefecture') is-invalid @enderror" name="prefectures[]" required multiple>
                                    @foreach($prefectures as $prefecture)
                                        <option value="{{ $prefecture }}" {{ in_array($prefecture, old('prefectures', [])) ? 'selected' : '' }}>{{ $prefecture }}</option>
                                    @endforeach
                                </select>
 
                                @error('prefectures')
                                    <span class="invalid-feedback" role="alert">
                                        <strong>{{ $message }}</strong>
                                    </span>
                                @enderror
                            </div>
                        </div>
...
@section('scripts')
<script type="module">
    document.addEventListener('DOMContentLoaded', function() {
        new TomSelect(document.getElementById('prefecture-multiple'), {
          maxOptions: null // 選択値制限なし
        ));
   })
</script>
@endsection

Tom Selectをviteでビルド

viteを使ってTom Selectのビルドを作成してみましょう。まず、Tom Selectのパッケージを以下でローカル環境にインストールします。

$ npm install tom-select --save-dev

そして、bootstrap.jsにおいてそれらをインポートします。

resources/js/bootstrap.js

import 'bootstrap';

import TomSelect from 'tom-select';
window.TomSelect = TomSelect;

// bootstrap5のcssをインポート
import '/node_modules/tom-select/dist/css/tom-select.bootstrap5.min.css';

viteの設定は以下となります。

vite.config.js

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/sass/app.scss',
                'resources/js/app.js',
            ],
            refresh: true,
        }),
    ],
});

最後に

$ npm run build

とビルドします。

Viteとselect2 ドロップダウン

Sat, 02 Aug 2025 06:51:28 +0900

昔のjQuery時代においてjquery-uiとともに有名となったのはselect2のウィジットです。オプションがたくさんあるドロップダウンでの選択や複数の値を選択を必要とされるときに非常に便利なもので、今でもその優れたUIは貴重です。今回はこれをviteでビルドします。

select2で選択

通常のドロップダウンは、以下のようにドロップダウンされた選択リストからクリックして選択です。

しかし、このオプションがたくさんあると探すのが大変。しかし、select2を使うと選択値の検索が可能となります。検索入力箱が表示され、赤箱の部分のように検索値を入れると、以下のようにフィルターされた結果から選択が可能となります。

通常のドロップダウンをselect2のドロップダウンにするのはとても簡単です。すでにwebpackなどでjqueryやselect2のライブラリがviteなどを利用してバンドルされていると仮定して、以下のようなブレードを作成します。

@php
    $prefectures = [
        '北海道', '青森県', '岩手県', '宮城県', '秋田県', '山形県', '福島県',
        '茨城県', '栃木県', '群馬県', '埼玉県', '千葉県', '東京都', '神奈川県',
        '新潟県', '富山県', '石川県', '福井県', '山梨県', '長野県',
        '岐阜県', '静岡県', '愛知県', '三重県',
        '滋賀県', '京都府', '大阪府', '兵庫県', '奈良県', '和歌山県',
        '鳥取県', '島根県', '岡山県', '広島県', '山口県',
        '徳島県', '香川県', '愛媛県', '高知県',
        '福岡県', '佐賀県', '長崎県', '熊本県', '大分県',
        '宮崎県', '鹿児島県', '沖縄県'
    ];
@endphp
@section('content')
<div class="container">
    <div class="row justify-content-center">
        <div class="col-md-8">
            <div class="card">
                <div class="card-header">会員登録</div>

                <div class="card-body">
                    <form method="POST" action="{{ route('register') }}">
                        @csrf
...
                        <div class="row mb-3">
                            <label for="prefecture" class="col-md-4 col-form-label text-md-end">都道府県</label>

                            <div class="col-md-6">
                                <select id="prefecture" class="form-select @error('prefecture') is-invalid @enderror" name="prefecture" required>
                                    @foreach($prefectures as $prefecture)
                                        <option value="{{ $prefecture }}" {{ old('prefecture') == $prefecture ? 'selected' : '' }}>{{ $prefecture }}</option>
                                    @endforeach
                                </select>

                                @error('prefecture')
                                    <span class="invalid-feedback" role="alert">
                                        <strong>{{ $message }}</strong>
                                    </span>
                                @enderror
                            </div>
                        </div>
...

@endsection

@section('scripts')
<script type="module">
    $(document).ready(function() {
        $('#prefecture').select2({
            theme: 'bootstrap-5',
        });
    });
</script>
@endsection

prefectureのDOMのノードにselect2のメソッドを装着するだけです。

select2で複数を選択

ドロップダウンで複数の選択が必要なときにselect2を使用すると、まず、何も選択されていないときは通常のドロップダウンのように表示されます。

そこで「北海道」を選択すると、以下のようにピルの形状で選択値が表示されます。そのピルの先頭にあるXをクリックして削除も可能です。

次に、検索してフィルターされた結果から検索して選択します。

選択後は以下のように複数の選択値がピルの形状で並びます。

こちらのブレードは、以下のようになります。

...
                      <div class="row mb-3">
                            <label for="prefecture-multiple" class="col-md-4 col-form-label text-md-end">都道府県(複数選択)</label>

                            <div class="col-md-6">
                                <select id="prefecture-multiple" class="form-select @error('prefecture') is-invalid @enderror" name="prefectures[]" required multiple>
                                    @foreach($prefectures as $prefecture)
                                        <option value="{{ $prefecture }}" {{ in_array($prefecture, old('prefectures', [])) ? 'selected' : '' }}>{{ $prefecture }}</option>
                                    @endforeach
                                </select>

                                @error('prefectures')
                                    <span class="invalid-feedback" role="alert">
                                        <strong>{{ $message }}</strong>
                                    </span>
                                @enderror
                            </div>
                        </div>
...
@section('scripts')
<script type="module">
    $(document).ready(function() {
        $('#prefecture-multiple').select2({
            theme: 'bootstrap-5',
            placeholder: '都道府県を選択してください',
        });
    });
</script>
@endsection

DOMのノードへのselect2のメソッドの装着は先の単一の選択とたいして変わりません。しかし、選択開始前に表示するplaceholderがオプションとして追加されています。

select2をviteでビルド

viteを使ってselect2のビルドを作成してみましょう。まず、select2とBootstrap 5のパッケージを以下でローカル環境にインストールします。

$ npm install select2 --save-dev
$ npm install select2-bootstrap-5-theme --save-dev

そして、bootstrap.jsにおいてそれらをインポートします。

resources/js/bootstrap.js

import 'bootstrap';
import JQuery from 'jquery';
window.$ = window.jQuery = JQuery;

import select2 from 'select2';
select2();　//　どうして必要なのかわからないけれど、これは必須！

// select2のcssをインポート
import "/node_modules/select2/dist/css/select2.min.css";
// さらに、bootstrap5のcssをインポート
import "/node_modules/select2-bootstrap-5-theme/dist/select2-bootstrap-5-theme.css";

viteの設定は以下となります。

vite.config.js

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/sass/app.scss',
                'resources/js/app.js',
            ],
            refresh: true,
        }),
    ],
});

最後に

$ npm run build

とビルドします。

PlaywrightでE2Eテストを自動化（１）セットアップ

Sun, 27 Jul 2025 01:52:33 +0900

このところ、AIの進化によりテストツールとしてのPlaywrightが便利だという話を目にする機会が多くなってきました。実際、2025年現在GoogleトレンドでもCypressやSeleniumの検索数を上回るなど、Playwrightへの注目度が高くなっているようです。以前に当ブログでCypressについてご紹介しましたが、Playwrightも気になったので少し触ってみました。

Playwrightとは

Playwrightとは、Microsoftが開発したE2E（End-to-End）テスト自動化ツールです。Webアプリケーションの動作を実際のブラウザで自動テストでき、Chrome、Firefox、Safari（WebKit）の3つのブラウザエンジンに対応しています。

ユーザーの操作を記録してテストコードを自動生成するcodegen機能や、GitHub Actionsとの連携によるコード変更時やデプロイ時の自動テスト実行も可能で、モダンなWeb開発ワークフローに適したツールとなっています。

インストール環境

Laravelで構築されたアプリケーションのE2EテストとしてPlaywrightを導入します。Laravelアプリとは異なるディレクトリにPlaywrightをインストールすることも可能ですが、今回はプロジェクトルートにインストールします。

Laravelのテストディレクトリとしてすでにtests/が存在するため、Playwright用ディレクトリはe2e/として以下の構成となるようインストールしてゆきます。

laravel-app/
├── app/
├── config/
├── database/
├── public/
├── resources/
├── routes/
├── tests/          # PHPUnit用のテスト
├── e2e/            # Playwright用のE2Eテスト ← ここ
├── package.json
└── composer.json

Playwrightインストール

まずはインストールです。最新版のインストールにはnode.jsのバージョン20、22もしくは24が必要です。

公式の手順にそって、プロジェクトのルートディレクトリで以下のコマンドを実行します。

$ npm init playwright@latest

いくつか質問されますので、プロジェクトに合う形で指定してゆきます。

.....
Do you want to use TypeScript or JavaScript? · TypeScript
Where to put your end-to-end tests? · e2e
Add a GitHub Actions workflow? (y/N) · false
Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) › true
.....

TypeScriptかJavaScriptか？では、今回はTypescriptを選択しました。また、Playwright用のテストケースを置くディレクトリはe2eに。

GitHub Actions workflowについては、初回は設定をシンプルに保ちたいのでfalseとしました。最後の「Install Playwright browsers」の質問では、Playwright専用のブラウザ（Chromium、Firefox、WebKit）を自動でダウンロードするかを選択できます。今回はtrueを選択して自動インストールしました。

インストールが完了すると、新しく以下のファイルが作成されます。

And check out the following files:
  - ./e2e/example.spec.ts - Example end-to-end test
  - ./tests-examples/demo-todo-app.spec.ts - Demo Todo App end-to-end tests
  - ./playwright.config.ts - Playwright Test configuration

/e2e/example.spec.tsは、テストの動作を確認するためのシンプルなサンプルテスト用のファイルです。 ./tests-examples/demo-todo-app.spec.tsも同じくサンプルテストですが、Playwrightが提供する実際のTodoアプリケーションを対象とした、より実践的なデモ用のE2Eテストが書かれたファイルとなっているようです。そして設定用のplaywright.config.tsが、ルートディレクトリにインストールされています。

Playwright設定ファイル

Playwrightの動作確認をする前に、playwright.config.tsの中を少し見てみます。

/playwright.config.ts

.....
export default defineConfig({
  testDir: './e2e',
  /* Run tests in files in parallel */
  fullyParallel: true,
  /* Fail the build on CI if you accidentally left test.only in the source code. */
  forbidOnly: !!process.env.CI,
  /* Retry on CI only */
  retries: process.env.CI ? 2 : 0,
  /* Opt out of parallel tests on CI. */
  workers: process.env.CI ? 1 : undefined,
  /* Reporter to use. See https://playwright.dev/docs/test-reporters */
  reporter: 'html',
  /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
  use: {
    /* Base URL to use in actions like `await page.goto('/')`. */
    // baseURL: 'http://localhost:3000',

    /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
    trace: 'on-first-retry',
  },
.....

インストール時に指定した通り、テストファイルの置き場所はtestDir: ‘./e2e’と設定されています。今のe2eディレクトリにはexample.spec.tsだけが入っており、新しいテストファイルはここに追加してゆく形ですね。

また初期設定ではコメントアウトとなっていますが、テスト内で相対パスを使う際のベースとなるbaseURLも項目として記載されています。

それ以外の主な設定として、以下のような項目が挙げられています。

fullyParallel：テストの並列実行
retries：テスト失敗時のリトライ設定
workers：並列実行のプロセス数
reporter：レポートの生成

サンプルテストを実行

では早速、サンプルテストを実行してみます。e2eディレクトリに存在するすべてのspec.tsファイルを対象にテストを実行する場合、以下のコマンドを使います。

%  npx playwright test

ファイルを指定して実行する場合は以下のいずれかで可能です。

$ npx playwright test example.spec.ts
$ npx playwright test example

コマンドを実行すると、ターミナルに以下が出力されました。

Running 6 tests using 4 workers
  6 passed (11.4s)

To open last HTML report run:

  npx playwright show-report

ヘッドレスモードでテストが実行されたようで、ブラウザも何も起動せずあっという間にテストが完了しました。ターミナルに出力されたメッセージに従って、以下のコマンドを実行します。

$ npx playwright show-report

localhost:9323でHTMLレポートが表示されました。Chrome、Firefox、Safari（webkit）でテストが実行されていますね。このレポートは、Macの場合 Ctrl+C で閉じることができます。

テストが問題なく実行されたことはわかりましたが、ブラウザが何も立ち上がらないのは少し心配ですので今度はオプションをつけて実行します。

$ npx playwright test --headed

–headedをつけて実行すると、一瞬ブラウザが立ち上がりましたがあっという間に閉じてテストが完了しました。サンプルテストなので早いというのはあるかもしれませんが、ブラウザの起動からテストが始まるまでがかなり早いように感じます。

また、テストを手動で１つづつ動かしながらブラウザでの動作も確認したいという場合は、–uiをつけて実行します。

$ npx playwright test --ui

PlaywrightのWebUIが立ち上がり、実行するテストファイル・テスト名などを選択して実行することができます。テストコードも下部に表示されるので、作成したテストコードの動作を確認しながら動かしたりエラー時のデバッグなどに使うと良さそうですね。

テスト失敗時

今度は失敗した場合の動作を確認します。example.spec.tsを一部編集して、エラーが起こるようにします。以下のtoHaveTitle(/Playwright/)の箇所で「アクセスしたページのタイトルに"Playwright"という文字列が含まれているか」をアサーションしていますので、“Plaaywright"とaを重複するよう書き換えてみます。

/e2e/example.spec.ts

.....
test('has title', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // Expect a title "to contain" a substring.
  await expect(page).toHaveTitle(/Plaaywright/); // aを重複するように編集
});
.....

これでテストを実行してみると、ターミナルへ以下のようなエラーメッセージ出力に加え、レポートが自動で立ち上がりました。

$ npx playwright test

Running 6 tests using 4 workers
  1) [chromium] › e2e/example.spec.ts:3:1 › has title ──────────────────────────────────────────────

    Error: Timed out 5000ms waiting for expect(page).toHaveTitle(expected)

    Locator: locator(':root')
    Expected pattern: /Plaaywright/
    Received string:  "Fast and reliable end-to-end testing for modern web apps | Playwright"
    Call log:
      - Expect "toHaveTitle" with timeout 5000ms
      - waiting for locator(':root')
        9 × locator resolved to <html lang="en" dir="ltr" data-theme="light" data-has-hydrated="true" data-theme-choice="system" class="plugin-pages plugin-id-default" data-rh="lang,dir,class,data-has-hydrated">…</html>
          - unexpected value "Fast and reliable end-to-end testing for modern web apps | Playwright"


       5 |
       6 |   // Expect a title "to contain" a substring.
    >  7 |   await expect(page).toHaveTitle(/Plaaywright/);
         |                      ^
       8 | });
       9 |
      10 | test('get started link', async ({ page }) => {
        at /Users/hiro/MySite/diary/e2e/example.spec.ts:7:22

    Error Context: test-results/example-has-title-chromium/error-context.md

  2) [firefox] › e2e/example.spec.ts:3:1 › has title 
.....

次回は、Playwrightの基本的なテストコードの書き方をご紹介します。

Viteとバニラjs – 日付選択とリスト並び替えのウィジット

Mon, 30 Jun 2025 11:26:23 +0900

前回ではviteでのjquery-uiパッケージ対応を説明しましたが、今度はjqueryをまったく使わない日付選択とリスト並び替えのウィジットの対応とします。かと言って、javascript（バニラJS？）でそれらのUIウィジットをスクラッチから作成するわけではありません。jquery-uiに取り替わるjqueryを必要としないパッケージを探します。

Vanilla JS Datepicker

日付の選択のパッケージはいくつかありますが、Vanilla JS Datepickerが良さそうです。jquery-uiのdatepickerの日付選択と同様に以下のようにカレンダーが表示できます。

jquery-uiとは違い、年の部分をクリックすれば以下のように月での選択を容易にしています。年の選択も同様に可能です。

ブレードでは以下のようにDOMのid (#datepicker) にDatePickerを関連付けます。jquery-uiと同様にローカライズや日付のフォーマットの指定も可能です。

<input type="tel" id="datepicker" name="start" class="form-control">
...
<script type="module">
    document.addEventListener('DOMContentLoaded', function() {
        const datepicker = document.getElementById('datepicker');
        if (datepicker) {
            new Datepicker(datepicker, {
                autohide: true,
                buttonClass: 'btn',
                format: 'mm/dd/yyyy', //　日付フォーマット
                language: 'ja', // 日本語化を指定
            });
        }
    });
</script>

このパッケージのドキュメントは以下からアクセスできます。 https://mymth.github.io/vanillajs-datepicker

SortableJS

jquery-uiのsortableの代わりとしては、SortableJSがおすすめです。

こちらはブレードでは以下のように設定が可能です。

<div class="row mb-3">
    <label class="col-md-4 col-form-label text-md-end">順番の並べ替え</label>
 
    <div class="col-md-6">
        <ol id="sortable">
            <li class="ui-state-default">アイテム 1</li>
            <li class="ui-state-default">アイテム 2</li>
            <li class="ui-state-default">アイテム 3</li>
        </ol>
    </div>
</div>
...
<script type="module">
    document.addEventListener('DOMContentLoaded', function() {
        Sortable.create(document.getElementById('sortable'));
    });
</script>

viteで対応

これらのパッケージをviteで対応（コンパイル）するには、

以下で２つパッケージと取り入れます。

$ npm install vanillajs-datepicker --save-dev 
$ npm install sortablejs --save-dev

次に、bootstrap.jsでそれらをインポートします。DatePickerでは、Bootstrap 5のためのCSSや日本語化を指定します。 SorableとDatepickerはwindow.をプレフィックスとしてグローバル変数としています。jQueryのインポートがないことに注意を。

resources/js/bootstrap.js

import Datepicker from 'vanillajs-datepicker/Datepicker';
import'vanillajs-datepicker/css/datepicker-bs5.min.css'; // Bootstrap 5を取り入れる
import ja from 'vanillajs-datepicker/locales/ja'; // 日本語を取り入れる
Object.assign(Datepicker.locales, ja);
window.Datepicker = Datepicker;

import Sortable from 'sortablejs';
window.Sortable = Sortable;

そして最後に、vite.config.jsの設定は以下のようになります。

vite.config.js

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/sass/app.scss',
                'resources/js/app.js',
            ],
            refresh: true,
        }),
    ],
});

Laravel FormRequestのユニットテスト（２）

Tue, 24 Jun 2025 08:48:33 +0900

FormRequestのユニットテスト２記事目の今回は、prepareForValidation()を含めてテストをしたい場合はどうするのか？についてご紹介します。前回に続いて、「店舗情報更新画面」のバリデーション・認可処理を行うShopUpdateRequestを例にテストを作成します。

前回の記事はこちらからどうぞ。

テスト対象

ShopUpdateRequestにはprepareForValidation()が定義されています。name要素の半角カタカナを全角カタカナに変換する、というものです。

・・・・・
    protected function prepareForValidation(): void
    {
        // 店舗名の半角カタカナを全角カタカナに変換
        $this->merge([
            'name' => mb_convert_kana($this->input('name') ?? '', 'KV'),
        ]);
    }
・・・・・

prepareForValidation()を含めたテスト

prepareForValidation()も含めてテストを行う場合、rules()単体のテストで使ったValidator::make()による検証ではprepareForValidation()は呼ばれないので、少し工夫する必要があります。

Laravel7の時に当サイトでご紹介したFormRequestのテストの記事で記載の$this->app->resolving…を使用した手法は現在も有効ですので、そちらを使って以下のようなテストを書くことができます。

    #[Test]
    #[DataProvider('validationWithKanaConversionDataProvider')]
    public function 店舗名の半角カタカナが全角カタカナに変換されること(array $input, string $expected): void
    {
        $input = array_merge(
            $input,
            [
                'description' => 'テスト用の説明文です',
                'active_flag' => 'Y'
            ],
        );

        $adminUser = User::factory()->create(['role' => 'admin']);
        $this->actingAs($adminUser);

        // インスタンス作成時に実行する処理を設定
        $this->app->resolving(ShopUpdateRequest::class, function ($resolved) use ($input) {
            $resolved->merge($input);
        });

        $request = app(ShopUpdateRequest::class);

        $this->assertEquals($expected, $request->input('name'));
    }

    public static function validationWithKanaConversionDataProvider(): array
    {
        return [
            '半角カタカナ' => [
                ['name' => 'ﾃｽﾄｼｮｯﾌﾟ'],
                'テストショップ',
            ],
            '漢字混在' => [
                ['name' => 'ﾃｽﾄ店舗'],
                'テスト店舗',
            ],
            '全角カタカナ' => [
                ['name' => 'テストショップ'],
                'テストショップ',
            ],
        ];
    }

app(ShopUpdateRequest::class)を実行した時点でprepareForValidation()だけでなくauthorize()、rules()、messages()の全てが呼ばれます。なのでauthorize()を設定している場合は認証を通すための準備も必要になりますので、ご注意ください。

FormRequest全体をテストしながら、ルートパラメータも取得したい場合

先ほどのコードでFormRequestの各メソッドを通した全体的なテストが可能となりましたが、ルートパラメータを取得してのテストも同時に行いたい場合は追加の情報が必要となります。前回の記事内、rules()単体のテストの項でご紹介したように、リクエストインスタンスにはルート情報がセットされていないからでしたね。

先ほどのテストコードにあった$this->app->resolving()の中でルート情報をセットできるように編集します。setRouteResolver()を使って、以下のように記述します。

・・・・・
        $this->app->resolving(ShopUpdateRequest::class, function ($resolved) use ($input, $shop) {
            $resolved->merge($input);

            $route = Route::getRoutes()->match($resolved);
            $route->setParameter('shop', $shop);
            $resolved->setRouteResolver(fn() => $route);
        });

        $request = app(ShopUpdateRequest::class);
・・・・・

ただ、ここまでするのであればFeatureテストで書いたほうがシンプルなテストコードで書けるかもしれませんね。

包括的なテストとメソッド単体のテストまとめ

FormRequest全体を通したテストを行えば、より実際の動作に近い形の検証が可能です。ですがシンプルなFormRequestの時や、バリデーションに焦点を当てたテストを書きたい場合などは、より軽量な方法としてrules()・autorize()単体のテストとするほうが良いと思いますので、FormRequestの内容に応じて使い分けたほうが良さそうです。

前回と今回の記事でご紹介したテストの書き方を簡単に以下にまとめましたので、FormRequestのテストを作成する際のご参考になれば嬉しいです。

テスト対象	テスト方法
`authorize()`	`$request->authorize()` を直接呼び出す
`rules()`	`Validator::make($data, $request->rules(), $request->messages())`
`rules()`（ルートパラメータ必要な場合）	`setRouteResolver()` でルート情報を設定
`prepareForValidation()` を含めた検証	`$this->app->resolving()` + `app(FormRequest::class)`
`prepareForValidation()` + ルートパラメータ	`resolving()` 内で `setRouteResolver()` でルート情報を設定

Viteとjquery-ui - 日付選択とリスト並び替えのウィジット

Mon, 16 Jun 2025 23:23:14 +0900

webpackベースのLaravel MixからViteへの移行の第２弾ですが、今回は私のお客さんのプロジェクトでも使用されているjquery-uiをViteで対応の話です。

jquery-ui

jQuery UIは、jQuerytライブラリの上に構築されたUIに関わるインタラクション、エフェクトとウィジェットのパッケージです。そのパッケージを使うと開発者は複雑なUIコンポーネントを簡単にプログラムに取り入れることができます。jQueryとともに長年に渡って現在もメンテされています。

どれほどシンプルに取り入れることが可能か、jQuery UIの日付選択とリスト並び替えのウィジットを見てみます。

まず、日付の選択のdatepickerのUIはこんな感じです。入力のテキストのところをクリックするとその下にカレンダーのウィジットが表示されて、日付を手動で入れることなくマウスで選択できます。

ブレードでは以下のように指定のDOMのid (#datepicker) にdatepicker()のメソッドを装着するだけです。言語の指定も、選択された日付のフォーマットも可能です。

<input type="text" id="datepicker" name="select_date" class="form-control">
...
<script type="module">
    $(document).ready(function() {
         $('#datepicker').datepicker({
              regional: "ja",　// 日本語化
              dateFormat: 'mm/dd/yy'　// 日付フォーマット
         });
    });
</script>

もちろん、昨今では、

<input type="date">

と入力のタイプをdateで指定するとカレンダーが出てきますが、表示されるカレンダーをブラウザーの言語に関わらず日本語で表示したり選択した日付を2025-06-14のようなフォーマットを変えたりなどは可能であってもjQuery UIのように容易には設定できません。

以下でjQurey UIのいろいろな機能のデモを見ることができます。 https://jqueryui.com/datepicker

次は、以下のようなリストやテーブルでの行の並び順を変えるsortable。

ブレードでは、こんな感じの指定です。こちらも指定のDOMのid (#sortable)にsortable()のメソッドを装着するだけで、マウスで指定の行をドラッグしてリストの順番を変えることができます。

<div class="row mb-3">
	<label class="col-md-4 col-form-label text-md-end">順番の並べ替え</label>

	<div class="col-md-6">
		<ol id="sortable">
			<li class="ui-state-default">アイテム 1</li>
			<li class="ui-state-default">アイテム 2</li>
			<li class="ui-state-default">アイテム 3</li>
		</ol>
	</div>
</div>
...
<script type="module">
    $(document).ready(function() {
         $('#sortable').sortable();
    });
</script>

viteで対応

さて、この素晴らしいjquery-uiパッケージをviteで対応するには、

まず、jqueryとjuquery-uiのnpmのパッケージを以下のコマンドで取り入れます。

$ npm install jquery jquery-ui --save-dev

さらに、以下のパッケージのrollupのinjectのプラグインも必要です。このプラグインの説明から察するに、jquery-uiのように$やjQueryのグローバル変数が設定されていると仮定するパッケージにおいてそれらを利用可能にするものと思われます。それらの指定は後にvite.config.jsで行います。これがないと動かないので必須です。

$ npm install @rollup/plugin-inject --save-dev

つぎに、bootstrap.jsでjqueryとjquery-uiをインポートします。また、カレンダーのローカライズのために、datepicker-ja.js、そしてウィジットのスタイルのために、jquery-ui.min.cssも指定が必要です。

reousrces/js/bootrap.js

import 'bootstrap';
import jQuery from 'jquery';
window.$ = window.jQuery = jQuery;

import 'jquery-ui/dist/jquery-ui';
import 'jquery-ui/ui/i18n/datepicker-ja.js';
import 'jquery-ui/dist/themes/base/jquery-ui.min.css';

そして最後に、vite.config.jsの設定は以下のようになります。先ほどのrolleupのプラグインのinjectの設定が必要なので注意を。

vite.config.js

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import inject from "@rollup/plugin-inject";

export default defineConfig({
    plugins: [
        inject({
            $: 'jquery',
            jQuery: 'jquery',
        }),
        laravel({
            input: [
                'resources/sass/app.scss',
                'resources/js/app.js',
            ],
            refresh: true,
        }),
    ],
});

そして、以下でビルドを実行して、ブラウザで見れるようにLaravelのウェブサーバーを立ち上げます。

$ npm run build & php artisan serve

もちろん、npm run devとして開発時のデバッグのためにホットリロードを可能としてもよいです。変更が瞬時にブラウザーに反映されて開発が楽しくなります。

今回はjquery-uiをviteで対応の話でしたが、次の投稿ではjqueryを使わない日付の選択とリストの並び替えのパッケージを将来する予定です。

Laravel FormRequestのユニットテスト（１）

Mon, 02 Jun 2025 01:29:15 +0900

Laravel12.xでFormRequestのユニットテストを作成します。今回の記事では基本的なテストから、少しややこしい$this->route()のようなルートパラメータを取得する必要がある場合の書き方などをご紹介します。

テスト対象

店舗情報の更新画面にて、入力データのバリデーション・認可処理を行うShopUpdateRequestが今回のテスト対象です。

入力項目は、店舗名（name）・店舗説明（description）・有効フラグ（active_flag）の３つ。rules()では必須チェックや文字数チェックなどの基本的なバリデーションと、nameに関しては他店舗と重複不可のユニーク制約も設定されています。

また、認可処理authorize()では管理者のみが実行可能なように設定されています。

App/Http/Requests/ShopUpdateRequest.php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Validation\Rule;

class ShopUpdateRequest extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     */
    public function authorize(): bool
    {
        return auth()->user()->role === 'admin';
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array<string, \Illuminate\Contracts\Validation\ValidationRule|array<mixed>|string>
     */
    public function rules(): array
    {
        $shop = $this->route('shop');

        return [
            'name' => [
                'required',
                'string',
                'max:20',
                Rule::unique('shops')->ignore($shop),
            ],
            'description' => ['required', 'string', 'max:100'],
            'active_flag' => ['required', Rule::in(['Y', 'N'])],
        ];
    }

    public function messages(): array
    {
        return [
            'name.required'        => '名前は必須です',
            'name.max'             => '名前は20文字以内で入力してください',
            'name.unique'          => 'この名前は既に使用されています',
            'description.required' => '説明は必須です',
            'description.max'      => '説明は100文字以内で入力してください',
            'active_flag.required' => 'アクティブフラグは必須です',
            'active_flag.in'       => 'アクティブフラグは Y または N で入力してください',
        ];
    }

    protected function prepareForValidation(): void
    {
        // 店舗名の半角カタカナを全角カタカナに変換
        $this->merge([
            'name' => mb_convert_kana($this->input('name') ?? '', 'KV'),
        ]);
    }
}

そしてコントローラー側では、以下のような定義となっています。

App/Http/Controllers/ShopController.php

・・・・・
use App\Http\Requests\ShopUpdateRequest;

class ShopController extends Controller
{
・・・・・
    public function update(ShopUpdateRequest $request, Shop $shop): RedirectResponse
    {
        $shop->update($request->validated());
        
        return redirect()->route('shops.show', $shop)
            ->with('success', '店舗情報を更新しました。');
    }
・・・・・
}

authorize()のテスト

まずはauthorize()のテストから。認証はadminユーザーのみ通ることができる、ということを検証します。

以下のようにRequestインスタンスから直接authorize()を呼び出してテストします。

Tests/Unit/Http/Requests/ShopUpdateRequestTest.php

namespace Tests\Unit\Http\Requests;

use App\Http\Requests\ShopUpdateRequest;
use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use PHPUnit\Framework\Attributes\Test;
use Tests\TestCase;

class ShopUpdateRequestTest extends TestCase
{
    use RefreshDatabase;

    #[Test]
    public function 管理者でないユーザーの場合は認証が通らない(): void
    {
        $normalUser = User::factory()->create(['role' => 'user']);
        $this->actingAs($normalUser);

        $request = new ShopUpdateRequest;
        $this->assertFalse($request->authorize());
    }

    #[Test]
    public function 管理者の場合は認証が通る(): void
    {
        $adminUser = User::factory()->create(['role' => 'admin']);
        $this->actingAs($adminUser);

        $request = new ShopUpdateRequest;
        $this->assertTrue($request->authorize());
    }
}

rules()のテスト

次に、rules()のテストです。正常系のテストは以下のように書くことができます。

Tests/Unit/Http/Requests/ShopUpdateRequestTest.php

・・・・・
use Illuminate\Support\Facades\Validator;
use PHPUnit\Framework\Attributes\DataProvider;
・・・・・

    #[Test]
    #[DataProvider('validationDataProvider')]
    public function 正常形のテスト(array $data): void
    {
        $rules = (new ShopUpdateRequest)->rules();

        $validator = Validator::make($data, $rules);

        $this->assertTrue($validator->passes());
    }

    public static function validDataProvider(): array
    {
        return [
            '文字数制限OK' => [
                [
                    'name'        => str_repeat('a', 20),
                    'description' => str_repeat('a', 100)
                    'active_flag' => 'Y',
                ],
            ],
        ];
    }

現時点で最新のLaravel12でも、テストの書き方は特に変わりません。このままデータプロバイダに他の正常系のパターンを追加していけばOKです。

次は異常系のテストです。エラーメッセージも同時に検証したいので、Validator::make()の第３引数にエラーメッセージの配列$request->messages()を渡しています。

Tests/Unit/Http/Requests/ShopUpdateRequestTest.php

・・・・・
    #[Test]
    #[DataProvider('invalidDataProvider')]
    public function 異常系のテスト(array $data, array $messages): void
    {
        $request = new ShopUpdateRequest;

        $validator = Validator::make($data, $request->rules(), $request->messages());

        $this->assertTrue($validator->fails());
        $this->assertSame($messages, $validator->errors()->toArray());
    }

    public static function invalidDataProvider(): array
    {
        return [
            '空値を許容しない' => [
                'data' => [
                    'name'        => '',
                    'description' => '',
                    'active_flag' => '',
                ],
                'messages' => [
                    'name'        => ['名前は必須です'],
                    'description' => ['説明は必須です'],
                    'active_flag' => ['アクティブフラグは必須です'],
                ],
            ],
            '文字数オーバー' => [
                'data' => [
                    'name'        => str_repeat('a', 21),
                    'description' => str_repeat('a', 101),
                    'active_flag' => 'Y',
                ],
                'messages' => [
                    'name'        => ['名前は20文字以内で入力してください'],
                    'description' => ['説明は100文字以内で入力してください'],
                ],
            ],
        ];
    }

このような形で、異常系もデータプロバイダにテストデータを追加していけばOKです。

ですが、nameプロパティで１つ問題があります。nameプロパティに設定されている以下のようなunique()制約は、このテストのままでは検証できません。

        $shop = $this->route('shop');
・・・・・
        Rule::unique('shops')->ignore($shop),

$this->route()で取得しているルートパラメーターは、現状のテストではnullとなってしまうからです。

テスト時は実際のHTTPリクエストとして実行するわけではないため、ルート情報が設定されていないことが原因のようです。テスト時にルートパラメータを取り扱うにはどうしたらいいでしょうか。

ルート情報を含んだリクエストインスタンスを作成する

ルートパラメータを含めたバリデーションテストをする場合、リクエストインスタンスにルート情報を設定する必要があります。

ここで、検証対象のルーティングを確認します。

PUT|PATCH   shops/{shop} ............................. shops.update › ShopController@update

ルーティング情報がわかったので、さっそくルート情報を持ったFormRequestインスタンスを作成してゆきましょう。まずはcreate()というFormRequestクラスに定義されているメソッドを使用します。

１. create()でリクエストインスタンスを作成

        $request = ShopUpdateRequest::create(
            route('shops.update', $shop),
            'PUT',
            $input
        );

第１引数にURL、第２引数にHTTPメソッド、第３引数に入力データを渡します。これで、ルーティング情報に合わせたリクエストインスタンスが作成できます。

入力情報もセットできているので、$request->input()での値取得も可能です。

よく使われる$request->merge($data)でも入力データをセットできますが、ルーティングがすでに用意されている場合は今回のようにcreate()を使うことで、より実際のHTTPリクエストに近い状況を作成することができます。

2. FormRequestクラスのsetRouteResolver()でルートパラメータを設定

リクエスト情報はセットできましたが、$this->route()を有効にするにはさらにルート情報をリクエストに適用する必要があります。インスタンスの作成に続いて、以下のようにデータを適用します。

        $request = ShopUpdateRequest::create(
         ・・・・・
        );

        // 実際のルートマッチングを取得し、リクエストに適用
        $route = Route::getRoutes()->match($request);
        $route->setParameter('shop', $currentShop);
        $request->setRouteResolver(fn () => $route);

setRouteResolver()は$requestにルートを紐付けるメソッドです。これでやっと、テストコード内で$this->route(‘shop’)でデータが取得できるようになりました。

ちゃんとデータが取得できるのかをtinkerでも確認してみます。

$ php artisan tinker                                                 
Psy Shell v0.12.8 (PHP 8.2.27 — cli) by Justin Hileman
> $shop = App\Models\Shop::factory()->create();                                                       
= App\Models\Shop {#6265
    name: "有限会社 桐山",
・・・・・

> $request = App\Http\Requests\ShopUpdateRequest::create(
    route('shops.update', $shop),    
    'PUT', 
    ['name' => 'テスト店舗', 'description' => 'テスト説明', 'active_flag' => 'Y']);

= App\Http\Requests\ShopUpdateRequest {#6306
・・・・・
  }

> $route = Route::getRoutes()->match($request);
= Illuminate\Routing\Route {#976
・・・・・

> $route->setParameter('shop', $shop);
= null

> $request->setRouteResolver(fn() => $route);
= App\Http\Requests\ShopUpdateRequest {#6306
・・・・・

> $request->route('shop');　　// これで取得できるようになった！
= App\Models\Shop {#6265
    name: "有限会社 桐山",
・・・・・

問題なく取得できています！

ルートパラメータを使ったunique制約のユニットテスト

上記の方法を使った「既存のショップ名と重複不可」の検証テストコードは、以下のようになります。

・・・・・
use App\Models\Shop;
use Illuminate\Support\Facades\Route;
・・・・・

    #[Test]
    public function 既存のショップ名と重複不可(): void
    {
        // 既存のショップを作成
        Shop::factory()->create(['name' => '既存のショップ名']);

        // 更新対象のショップを作成
        $currentShop = Shop::factory()->create(['name' => '現在のショップ名']);

        // 更新リクエストのデータ
        $input = [
            'name'        => '既存のショップ名', // 既存のショップ名と重複
            'description' => 'テスト用の説明文です',
            'active_flag' => 'Y',
        ];

        // リクエストインスタンスの作成
        $request = ShopUpdateRequest::create(
            route('shops.update', $currentShop),
            'PUT',
            $input
        );

        // 実際のルートマッチングを取得し、リクエストに適用
        $route = Route::getRoutes()->match($request);
        $route->setParameter('shop', $currentShop);
        $request->setRouteResolver(fn () => $route);

        // バリデーション実行
        $validator = Validator::make($request->all(), $request->rules(), $request->messages());

        // バリデーションが失敗することをアサート
        $this->assertTrue($validator->fails());

        // エラーメッセージに重複エラーが含まれることをアサート
        $this->assertTrue($validator->errors()->has('name'));
        $this->assertEquals('この名前は既に使用されています', $validator->errors()->first('name'));
    }

テストデータ準備のため少しコードが長くなりましたが、バリデーションの実行・アサートの部分は先ほどの異常系のテストと同じです。

次回は引き続き、prepareForValidation()を含めたテストの書き方をご紹介します。

ViteとBootstrap(sass)とjQuery

Sun, 11 May 2025 01:22:18 +0900

前のことになりますが、Laravelのバージョン8以降よりユーザー画面のアセットのビルドのためにViteが登場しています。しかし私のプロジェクトでは、Boostrapのフレームワークを使用しておりjQueryとその関連のライブラリをヘビーに使用していてなかなか従来のwebpackベースのLaravel Mixからは抜け出すことができません。何度かは試みたものの解決できないエラーが出て挫折を繰り返すのみでした。しかし、最近やっとその移行に光が見えてきました。Viteのビルドのスピードと開発環境は良いです。

基本的に私が抱えるプロジェクトは、画面のUIはSassベースのBootstrapのフレームワークを使用、そしてそれに関連するjsのライブラリはほとんどがjQueryベースです。Laravelが存在する以前のフレームワークなしのPHPで開発されLaravelに進化した大きなプロジェクトで、そう簡単に流行りのテクノロジーには乗り換えることはできません。今回は、そのようなプロジェクトのためのViteへの移行の話です。

Vite

まず、Viteを説明するために、最新のLaravel 12.xのプロジェクトを作成します。

$ composer create-project laravel/laravel l12x-vite

この時点で、UIのアセットの元となるresourcesディレクトリはこんな感じです。

├── css
│   └── app.css
├── js
│   ├── app.js
│   └── bootstrap.js
└── views
    └── welcome.blade.php

上において、app.cssはtailwindcssのための設定ファイルで、

resources/css/app.css

@import 'tailwindcss';

@source '../../vendor/laravel/framework/src/Illuminate/Pagination/resources/views/*.blade.php';
@source '../../storage/framework/views/*.php';
@source '../**/*.blade.php';
@source '../**/*.js';

@theme {
    --font-sans: 'Instrument Sans', ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji',
        'Segoe UI Symbol', 'Noto Color Emoji';

bootstrap.jsでは、ajaxのためのaxiosのパッケージがimportされ、

resources/js/bootstrap.js

import axios from 'axios';
window.axios = axios;

window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';

さらにapp.jsにおいて、そのbootstrap.jsをimportしています。

resources/js/app.js

import './bootstrap';

そして以下がViteの設定ファイルvite.config.jsです。resources下のファイルが指定されていることがわかります。

vite.config.js

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/css/app.css',
                'resources/js/app.js',
            ],
            refresh: true,
        }),
    ],
});

また、上では、laravel-vite-pluginがimportされていますが、これが以前のlaravel-mixのようなもので、Viteの設定をとてもシンプルにし、LaravelにおいてUI開発を簡単にします

Viteのアクションを見るには、まず、package.jsonに含まれるパッケージをダウンロードしてnode_modulesのディレクトリにインストールします。

$ npm install

そして、Viteを使ってアセットのビルドをします。

$ npm run build

注意：npm run devによるhotの方の説明は違う機会にします。そちらもUI開発のためのViteの優れた機能です。

このビルドにより、public/buildの以下のファイルが作成されます。

public/build
├── assets
│   ├── app-D4mwfHMp.css
│   └── app-T1DpEqax.js
└── manifest.json

$ php artisan serve

を実行して、http://127.0.0.1:8000/にアクセスすると、

この画面のソースを見ると、ビルドで作成されたファイルが使用されているのがわかります。

<html lang="en">
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">

        <title>Laravel</title>

        <!-- Fonts -->
        <link rel="preconnect" href="https://fonts.bunny.net">
        <link href="https://fonts.bunny.net/css?family=instrument-sans:400,500,600" rel="stylesheet" />

        <!-- Styles / Scripts -->
        <link rel="preload" as="style" href="http://127.0.0.1:8000/build/assets/app-D4mwfHMp.css" />
        <link rel="modulepreload" href="http://127.0.0.1:8000/build/assets/app-T1DpEqax.js" />
        <link rel="stylesheet" href="http://127.0.0.1:8000/build/assets/app-D4mwfHMp.css" />
        <script type="module" src="http://127.0.0.1:8000/build/assets/app-T1DpEqax.js"></script>            
    </head>
...

元のブレードファイルを見ると、@viteのディレクティブが使用されているのがわかります。

resources/views/welcome.blade.php

<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">

        <title>Laravel</title>

        <!-- Fonts -->
        <link rel="preconnect" href="https://fonts.bunny.net">
        <link href="https://fonts.bunny.net/css?family=instrument-sans:400,500,600" rel="stylesheet" />

        <!-- Styles / Scripts -->
        @if (file_exists(public_path('build/manifest.json')) || file_exists(public_path('hot')))
            @vite(['resources/css/app.css', 'resources/js/app.js'])
        @else
            <style>
...

Viteで作成されたmanifest.jsonには、

public/build/manifest.json

{
  "resources/css/app.css": {
    "file": "assets/app-D4mwfHMp.css",
    "src": "resources/css/app.css",
    "isEntry": true
  },
  "resources/js/app.js": {
    "file": "assets/app-T1DpEqax.js",
    "name": "app",
    "src": "resources/js/app.js",
    "isEntry": true
  }
}

のデータがあるので、これをもとにLaravelが@viteで指定されているアセットを実際のファイルに置き換えて表示します。このメカニズムは、以前のlaravel-mixでのmix()ヘルパーのようなものです。目的は同じく更新したcssやjsのファイルが同じファイル名でブラウザにキャッシュされないためです。

BootstrapのSass

Laravelのデフォルトのプロジェクトはtailwindcssの使用ですが、Bootstrapで使用されているSassの対応のためには、Viteの設定ファイルを変更する必要あります。

laravel/uiがいまだにBootstrapをサポートしているのでそれを利用してみます。先で作成されたプロジェクトに、laravel/uiをインストールして、bootstrapをUIとして指定します。-authはユーザーの登録やログイン画面の機能も追加します。

$ composer require laravel/ui
$ php artisan ui bootstrap --auth

この後に、vite.config.jsを見てみますと、

vite.config.js

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/sass/app.scss',
                'resources/js/app.js',
            ],
            refresh: true,
        }),
    ],
});

resources/css/app.cssがresources/sass/app.scssとなりBootstrapのsassのファイルをポイントしています。

jsの方では、bootstrap.jsにおいて、bootstrapをimportするように変更されています。注意：このファイル名とCSSのフレームワークのBootsrapと混乱しないように。ここでのbootstrap.jsという名前は単にLaravelのプロジェクトのブートストラップという意味だけで、必要なJSパッケージをインポートするための目的です。

resources/js/bootstrap.js

import 'bootstrap'; 

import axios from 'axios';
window.axios = axios;

window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';

package.jsonには、bootstrapとsassのパッケージがlarave/uiのインストールで追加されているので、この時点でそれらをダウンロードします。

$ npm install

そして、以下でビルドを実行して、ブラウザで見れるようにLaravelのウェブサーバーを立ち上げます。

$ npm run build & php artisan serve

ブラウザのURLにおいて、以下を指定します。注意：http://127.0.0.1:8000/でアクセスすると崩れているページとなります。それは、welcome.blade.phpがtailwindcssのままでbootstrapに変更されていないからです。

http://127.0.0.1:8000/register

ブラウザでは以下のような画面になり、まずは成功です。

jQuery

次は、jQueryの対応です。まず、npmでjqueryをインストールします。

$ npm install --save-dev jquery

次に、bootstrap.jsを編集します。

resources/js/bootstrap.js

import 'bootstrap';
import JQuery from 'jquery';
window.$ = window.jQuery = JQuery; // グローバルで$やjQueryを使えるようにする
...

ユーザー登録のブレードにおいて、jqueryを使用したスクリプトを入れてみます。パスワードが８文字以上が必要なことを警告するメッセージを表示するスクリプトです。

resources/views/auth/register.blade.php

@extends('layouts.app')

@section('content')
<div class="container">
    <div class="row justify-content-center">
        <div class="col-md-8">
            <div class="card">
                <div class="card-header">{{ __('Register') }}</div>
...
@endsection

@section('scripts')
<script type="module">
    $(document).ready(function() {
        const minPasswordLength = 8; // 最小パスワード長

        // passwordの項目の後に、パスワードの長さに関する説明を追加
        $('#password').after('<small class="form-text text-muted password-help">パスワードは最低' + minPasswordLength + '文字必要です</small>');

        // passwordの項目に入力があった場合、パスワードの長さをチェック
        $('#password').on('input', function() {
            const passwordValue = $(this).val();
            const passwordHelp = $('.password-help');

            if (passwordValue.length < minPasswordLength) {
                $(this).removeClass('is-valid').addClass('is-invalid');
                passwordHelp.removeClass('text-muted text-success').addClass('text-danger');
            } else {
                $(this).removeClass('is-invalid').addClass('is-valid');
                passwordHelp.removeClass('text-muted text-danger').addClass('text-success');
            }
        });
    });
</script>
@endsection

上で注意することは、必ず

Laravel on ララジャパン

ローカル開発環境のPlaywrightテストをTestMu AI（LambdaTest）で実行

本記事のゴール：公開サイトからローカル環境のテストまで

LambdaTestの接続情報を取得

デモサイトへアクセスするテスト

公開ページにアクセスするための設定ファイル

②デバイスマッピング

③LambdaTestへの接続設定

④Playwrightの実行設定

デモサイトへのテスト実行

Tunnelバイナリ管理のライブラリ

Tunnel実行ファイル

playwright.lambdatest.config.tsを更新

テスト実行

safari/ios対応

deployerで複数サイトを管理（２）タスクを定義

Laravelアプリをダウンさせるタスクを定義

タスクを強化

deployerで複数サイトを管理（１）

Deployerのインストール

Deployerの初期化

複数のサイトにいっぺんにアクセス

ホスト情報をYAMLファイルにする

PlaywrightでE2Eテストを自動化（６）開発DBとテストDBの分離と初期化

プロジェクトの構成

.env.playwright

.env.playwrightをconfigファイルに追加

Playwright用のSeeder

Seeder実行ファイルの作成と設定

DBセットアップファイルをconfigファイルで読み込む

webServerの設定

最終的なplaywright.config.ts

Playwrightでコンポーネント単位のPOMを導入し、テストで使い回す

POM化対象の要素

POM導入前のテストコード

対象要素をPOM化する

作成したPOMをテストコードで使う

FixtureでPOMを定義する

POM導入後のテストコード

ウェブからバックグラウンドでプログラムを実行

準備

ウェブと同じプロセスで同期実行（deferred）

ウェブと違うプロセスで同期実行（background）

deferred vs background

ミドルウェアをもっと知ろう （４）コントローラに装着

カスタムに作成したミドルウェア

グローバルでの装着

ルートで装着

コントローラで装着

PlaywrightでE2Eテストを自動化 （５）Authenticationでログイン処理を簡略化

Authenticationとは

Authenticationの設定方法

playwright/.auth ディレクトリの作成

セットアップ用ファイルを作成

configファイルに定義

テストファイルでuseする

テストの実行時

全体を認証済みとし、特定のテストだけ認証状態をリセットする場合

テスト時間が変わるのか確認

開発のタスクを整理するためのツール

開発に必要なタスクの種類

コード作成後に実行するタスク

ローカル開発環境を立ち上げるタスク

インストール作業のためのタスク

composer

npm

make

Pest4のE2Eテスト - セットアップ〜テストコードの実装例

セットアップ

新規作成フロー・テストコード全体

画面遷移・操作系メソッド

要素の値を取得するメソッド

セレクタの指定について

アサーション系

使用可能なLaravelのメソッド

Playwrightのメソッドを使いたい場合

まとめ

第２のデータベースにアクセス

データベースのコネクション

扱うデータベースが２つのとき

ミドルウェアをもっと知ろう（４）コントローラに装着

PlaywrightでE2Eテストを自動化（５）Authenticationでログイン処理を簡略化

PlaywrightでE2Eテストを自動化（４）Agents × Claude Code

PlaywrightでE2Eテストを自動化（３）codegenでコード生成

PlaywrightでE2Eテストを自動化（２）ログイン・ログアウト