Test 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倍〜時間がかかる感じがします。

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を導入できるので、ぜひ使ってみてください！

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を使用している方はぜひ試してみてください。

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テストに使用できます。その点が他と比べてもとても便利だと感じました。

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テスト作成〜実行が現実味を帯びてきたなと感じます。

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が生成したコードの差異を出さないためにも生成コードに寄せていったほうがいいのかな、と思いました。

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を使ってテストコードを作成します。

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の基本的なテストコードの書き方をご紹介します。

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()` でルート情報を設定

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()を含めたテストの書き方をご紹介します。

Pestの「dataset」活用で、見通しが良い・修正しやすいテストコードへ

Sun, 09 Mar 2025 08:39:49 +0900

テストを書くとき、テストパターンや入力値の組み合わせが増え、データの管理が煩雑になりがちです。Pestではwith()やdataset()を使って基本的なデータ整理ができますが、後から読んでも理解しやすい・修正しやすいコードを目指して、Combining DatasetsやSharing Datasetsを活用し、テストコードを整理してみます。

テスト対象

テスト対象は以下のクラスです。calculateShippingCost()は、引数として渡された温度帯と配送地域の値に応じて送料を計算する関数です。

class ShippingCalculator
{
    private static array $tempCosts = [
        '常温' => 0,
        '冷蔵' => 200,
        '冷凍' => 500,
    ];

    private static array $regionCosts = [
        '東京' => 500,
        '大阪' => 750,
        '福岡' => 1000,
    ];

    /**
     * 温度帯と配送地域から送料を計算する
     */
    public static function calculateShippingCost(string $temp, string $region): int|string
    {
        if (!array_key_exists($temp, self::$tempCosts) || !array_key_exists($region, self::$regionCosts)) {
            return '計算不可';
        }
    
        $baseCost = self::$regionCosts[$region];

        $tempCost = self::$tempCosts[$temp];
        
        return $baseCost + $tempCost;
    }
}

例えば、温度帯が「冷蔵」の場合は200円、配送地域が「大阪」の場合は750円を取得し、合計送料として950円を返します。

> ShippingCalculator::calculateShippingCost('冷蔵', '大阪');
= 950

また、定義されていない値が渡された場合は「計算不可」が返ります。

> ShippingCalculator::calculateShippingCost('でたらめ', '大阪');
= "計算不可"

テストコード

以下はcalculateShippingCost()の計算結果が正しいことを検証するテストコードです。

テストのパターンとして、温度帯と配送地域をいくつかピックアップしてテストする形でもいいかもしれませんが、今回は全ての組み合わせ（３つの温度帯×３つの配送地域 = ９パターン）をテストします。

it('全ての組み合わせパターンで送料を検証', function (string $temp, int $tempCost, string $region, int $regionCost) {

    // 期待される合計送料
    $expected = $tempCost + $regionCost;
        
    // 実際の計算結果
    $actual = ShippingCalculator::calculateShippingCost($temp, $region);
    
    expect($actual)->toBe($expected);
})
->with([
    ['常温', 0, '東京', 500],    // １回目
    ['常温', 0, '大阪', 750],    // ２回目
    ['常温', 0, '福岡', 1000],   // ３回目
    ['冷蔵', 200, '東京', 500],  // ４回目
    ['冷蔵', 200, '大阪', 750],  // ５回目
    ['冷蔵', 200, '福岡', 1000], // ６回目
    ['冷凍', 500, '東京', 500],  // ７回目
    ['冷凍', 500, '大阪', 750],  // ８回目
    ['冷凍', 500, '福岡', 1000], // ９回目
]);

Pestでは、with()を使用してデータパターンをテストに渡します。with()には複数のテストデータを配列で渡せるため、今回のように多次元配列を使うことで、各配列が1回分のテストデータとして処理されます。

まずはwith()に９パターンを直接記述しましたが、パターンが多いとテストコードと繋がって少しごちゃごちゃして見えますね。そういう場合はdataset()を使用すると、以下のようにテストとパターンを分離させて書くことができます。

it('全ての組み合わせパターンで送料を検証', function (string $temp, int $tempCost, string $region, int $regionCost) {
・・・テストコードは同じ
})
->with('shippingCosts');

dataset('shippingCosts', [
    ['常温', 0, '東京', 500],
    ['常温', 0, '大阪', 750],
    ['常温', 0, '福岡', 1000],
    ['冷蔵', 200, '東京', 500],
    ['冷蔵', 200, '大阪', 750],
    ['冷蔵', 200, '福岡', 1000],
    ['冷凍', 500, '東京', 500],
    ['冷凍', 500, '大阪', 750],
    ['冷凍', 500, '福岡', 1000],
]);

dataset()は第一引数にデータセット名を、第二引数は先ほどwith()に渡していたデータの配列を指定します。

そしてwith()の方へはデータセット名を指定するだけで良いのでテストが少しすっきりと、可読性が良くなりました。

Combining Datasetsの活用

ここまでの書き方でも問題ありませんが、９パターンが並んでいて分かりにくい点や、パターンが増減した際の修正が大変な点が気になります。

そこで、Combining Datasetsを活用します。全ての組み合わせをテストする時はCombining Datasetsを使うとコードをとても簡潔に書くことができます。

まずは９パターンあったデータセットを、「温度帯」と「配送地域」のそれぞれのデータセットに分けて作成します。

dataset('tempWithCost', [
    ['常温', 0],
    ['冷蔵', 200],
    ['冷凍', 500],
]);

dataset('regionWithCost', [
    ['東京', 500],
    ['大阪', 750],
    ['福岡', 1000],
]);

「温度帯」の３パターンはtempWithCostに、「配送地域」の３パターンはregionWithCostと定義しました。

そしてこれをテスト側でどう呼び出すかというと、以下のようにwith()を連結させるだけです。

it('全ての組み合わせパターンで送料を検証', function (string $temp, int $tempCost, string $region, int $regionCost) {
...
})
->with('tempWithCost')
->with('regionWithCost');

ちゃんと９パターン全て網羅されるのか、テストを実行して確認します。

PASS  Tests\Unit\ShippingCalculatorTest
  ✓ it 全ての組み合わせパターンで送料を検証 with ('常温', 0) / ('東京', 500)                                                                                                0.01s  
  ✓ it 全ての組み合わせパターンで送料を検証 with ('常温', 0) / ('大阪', 750)                                                                                                0.01s  
  ✓ it 全ての組み合わせパターンで送料を検証 with ('常温', 0) / ('福岡', 1000)                                                                                               0.01s  
  ✓ it 全ての組み合わせパターンで送料を検証 with ('冷蔵', 200) / ('東京', 500)                                                                                              0.01s  
  ✓ it 全ての組み合わせパターンで送料を検証 with ('冷蔵', 200) / ('大阪', 750)                                                                                              0.01s  
  ✓ it 全ての組み合わせパターンで送料を検証 with ('冷蔵', 200) / ('福岡', 1000)                                                                                             0.01s  
  ✓ it 全ての組み合わせパターンで送料を検証 with ('冷凍', 500) / ('東京', 500)                                                                                              0.01s  
  ✓ it 全ての組み合わせパターンで送料を検証 with ('冷凍', 500) / ('大阪', 750)                                                                                              0.01s  
  ✓ it 全ての組み合わせパターンで送料を検証 with ('冷凍', 500) / ('福岡', 1000)                                                                                             0.01s

問題なさそうです。出力にはテスト名だけでなく、どのパターンの組み合わせかも表示してくれています。ちなみにテスト失敗時は以下のようになり、どのケースで失敗したかも分かりやすいです。

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 FAILED  Tests\Unit\ShippingCalculatorTest > it 全ての組み合わせパターンで送料を検証 with ('冷凍', 500) / ('九州', 1000)                                                         
  Failed asserting that '計算不可' is identical to 1500.

データセットの再利用

dataset()でデータセットとテストを分離しておくと、他のテストでも再利用することができます。

例としてもう１つテストを作成します。今度は、定義されていない温度帯の場合は"計算不可"が返るパターンのテストです。

it('存在しない温度帯は計算不可を検証', function (string $temp, string $region) {

    $actual = ShippingCalculator::calculateShippingCost($temp, $region);
    
    expect($actual)->toBe('計算不可');
})
->with(['cool', '　', '存在しない温度帯'])
->with('regionWithCost');

こちらもCombining Datasetsを使用しており、１つめのwith()には失敗パターンの温度帯データを直接記述しています。

そして２つ目のwith()には、すでに定義済みのregionWithCost（配送地域のデータセット）を渡しました。

このように、テストコード内でパターンを重複することなく複数のテストで共有できます。テストを実行してみましょう。

   PASS  Tests\Unit\ShippingCalculatorTest
  ✓ it 存在しない温度帯は計算不可を検証 with ('cool') / ('東京', 500)                                                                                                   0.01s  
  ✓ it 存在しない温度帯は計算不可を検証 with ('cool') / ('大阪', 750)                                                                                                   0.01s  
  ✓ it 存在しない温度帯は計算不可を検証 with ('cool') / ('福岡', 1000)                                                                                                  0.01s  
  ✓ it 存在しない温度帯は計算不可を検証 with ('　') / ('東京', 500)                                                                                                      0.01s  
  ✓ it 存在しない温度帯は計算不可を検証 with ('　') / ('大阪', 750)                                                                                                      0.01s  
  ✓ it 存在しない温度帯は計算不可を検証 with ('　') / ('福岡', 1000)                                                                                                     0.01s  
  ✓ it 存在しない温度帯は計算不可を検証 with ('存在しない温度帯') / ('東京', 500)                                                                                               0.01s  
  ✓ it 存在しない温度帯は計算不可を検証 with ('存在しない温度帯') / ('大阪', 750)                                                                                               0.01s  
  ✓ it 存在しない温度帯は計算不可を検証 with ('存在しない温度帯') / ('福岡', 1000)                                                                                              0.01s

こちらも問題なく全ての組み合わせでテストできました！

datasetをファイルへ切り出す

ここまでは、テストコードとデータセットが１つのファイルに共存している状態でした。Pestではデータセットをtests/Datasetsへ切り出すことで、他のテストファイルからも呼び出せるようになるSharing Datasetsという機能があります。

データセットをファイルに切り出す際、Laravel環境では前回ご紹介したプラグインををインストールしていると以下のコマンドで簡単にファイルを作成できます。もちろん手動で作成しても問題ありません。

$ php artisan pest:dataset shippingCosts

ファイル名はshippingCostsとしました。ここに、先ほどのデータセットを移行します。テストファイルに記述していたdataset()をそのままコピーすればOKです。

/tests/Datasets/ShippingCosts.php

dataset('tempWithCost', [
    ['常温', 0],
    ['冷蔵', 200],
    ['冷凍', 500],
]);

dataset('regionWithCost', [
    ['東京', 500],
    ['大阪', 750],
    ['福岡', 1000],
]);

これで、テストコードとデータセットを完全に分離できました！

最初のテストコードよりはかなりすっきりしたのではないでしょうか。Pestでテストを作成する際は、ぜひ活用してみてください。

Test on ララジャパン

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

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

LambdaTestの接続情報を取得

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

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

②デバイスマッピング

③LambdaTestへの接続設定

④Playwrightの実行設定

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

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

Tunnel実行ファイル

playwright.lambdatest.config.tsを更新

テスト実行

safari/ios対応

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導入後のテストコード

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

Authenticationとは

Authenticationの設定方法

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

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

configファイルに定義

テストファイルでuseする

テストの実行時

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

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

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

セットアップ

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

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

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

セレクタの指定について

アサーション系

使用可能なLaravelのメソッド

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

まとめ

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

テスト対象のサイト

準備・セットアップ

plannerでテストプランを作成

generator・healerでE2Eテストを作成

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

まとめ

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

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

codegenで動作を記録

codegenでアサートを追加

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

不要なコードを削除

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

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

テスト対象

ログイン・ログアウトのテストコード

Playwrightの構文

Playwrightのコマンド

Playwrightのアサーション

BaseURLを設定

共通処理を関数へ切り出し

PlaywrightでE2Eテストを自動化（１）セットアップ

Playwrightとは

インストール環境

Playwrightインストール

Playwright設定ファイル

サンプルテストを実行

テスト失敗時

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

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

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

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