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

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でテストを作成する際は、ぜひ活用してみてください。

テストがちょっとシンプルになる pest-plugin-laravel プラグイン

Thu, 13 Feb 2025 08:36:45 +0900

PestはPHPUnitの上に構築された、テストをよりシンプルに書くためのフレームワークです。そのPestが公式に推奨しているLaravelのためのプラグインpest-plugin-laravelを使って既存のテストを書き直してみました。Pestが掲げる「読みやすく理解しやすい」テストコードに、少し近づけるでしょうか。

Pest導入、基本の記述方法については以下をご参照ください。 PHPUnitテストをpest-plugin-driftでPestへ変換 Pestでモック・例外のテスト

pest-plugin-laravelをインストール・テストファイル作成

Pestはすでにインストールしてあると仮定して、以下のコマンドでプラグインをインストールします。

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

このプラグインをインストールしたことで、まず、新しいartisanコマンドpest:testが使えるようになっています。ファイル名をPestTestと指定して以下のコマンドを実行します。

$ php artisan pest:test PestTest

tests/Feature/PestTest.phpにテストファイルが作成されます。

tests/Feature/PestTest.php

it('has pest page', function () {
    $response = $this->get('/pest');

    $response->assertStatus(200);
});

デフォルトでは、tests/Featureのディレクトリにファイルが作成されますが、–unitオプションをつけるとtest/Unitにファイルが作成されます。

もちろん、Laravel標準のmake:testコマンドで作成しても問題ありません。

$ php artisan make:test PestTest

pest-plugin-laravelを使った記述方法

プラグインインストールでテストの記述も少し簡単になります。Laravelのテストでよく使うテストヘルパーを$this->を使わず呼び出せるようになります。例えば以下のようなユーザーログアウトのテストの場合

test('users can logout', function () {

    $this->actingAs($this->user)
        ->post('/logout')
        ->assertRedirect('/');

    $this->assertGuest();
});

プラグインの機能を使って書き直すと、こんな風になります。

use function Pest\Laravel\{actingAs, assertGuest}; // インポートする

test('users can logout', function () {

    actingAs($this->user)
        ->post('/logout')
        ->assertRedirect('/');

    assertGuest();
});

actingAsやassertGuestを直接呼び出すことができるようになるため、$this->の記述がなくなってコードが少しすっきりしました。名前空間関数のインポートが必要ですので、useをお忘れなく。

他にも、よく使われるHTTPリクエストの場合

プラグイン導入前

...
    $response = $this->get('/login');
...
    $response = $this->post('/login', [
        'email'    => 'test@example.com',
        'password' => 'password',
    ]);
...

導入後

use function Pest\Laravel\{get, post};

...
    $response = get('/login');
...
    $response = post('/login', [
        'email'    => 'test@example.com',
        'password' => 'password',
    ]);
...

データベースのアサーションは

プラグイン導入前

...
    $this->assertDatabaseHas(User::class, ['email' => 'test@example.com']);
...

導入後

use function Pest\Laravel\assertDatabaseHas;
...
    assertDatabaseHas(User::class, ['email' => 'test@example.com']);
...

他にも色々なコマンドが対応していますので、詳しくはgithubをご覧ください。

プラグインの機能を使って、以前にご紹介したパスワードリセットのテストをPest形式に書き換えたものが以下になります。（書き換え前のPHPUnitのテストコードはリンクからご確認ください）

use function Pest\Laravel\{post, assertGuest, assertAuthenticated};

test('password can be reset with valid token', function () {
    Notification::fake();

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

    post('/forgot-password', ['email' => $user->email]);

    Notification::assertSentTo($user, ResetPassword::class, function ($notification) use ($user) {
        $response = post('/reset-password', [
            'token' => $notification->token,
            'email' => $user->email,
            'password' => 'new_password',
            'password_confirmation' => 'new_password',
        ]);

        $response->assertRedirect('login')
            ->assertSessionHas('status', 'パスワードをリセットしました。');

        return true;
    });

    assertGuest();

    post('/login', [
        'email' => $user->email,
        'password' => 'new_password',
    ]);

    assertAuthenticated();
});

post・assertGuest・assertAuthenticatedの箇所が、$this->を省略した形に置き換えられています。「すごく変わった！」という訳ではないものの、やはり元のテストよりは細かい部分が見やすくなっています。テストコードが増えてくるとかなり違いがあるのではないでしょうか。

データセット

もう１つ、このプラグインが提供しているコマンドpest:datasetをご紹介します。

$ php artisan pest:dataset データセット名

このコマンドはtests/Datasets/にデータセット用のファイルを作成してくれます。データセットの機能自体は元からPestにあるものですが、artisanコマンドを使ってより便利に作成できるようになりました。

例として、以下のテストからデータセットを別ファイルに切り出してみます。ログインに失敗するテストと、そのデータセットをwith()で渡しています。

test('users cannot authenticate with invalid credentials', function (string $email, string $password) {
    post('/login', [
        'email'    => $email,
        'password' => $password,
    ])->assertStatus(302);

    assertGuest();
})->with([
    '間違ったパスワード'    => ['test@example.com', 'wrong-password'],
    '間違ったメールアドレス' => ['wrong@example.com', 'password'],
]);

まずはデータセットのファイルを作成します。ファイル名はLoginDataとて、以下のコマンドを実行します。

$ php artisan pest:dataset LoginData

これでtests/Datasetsにファイルが作成されましたので、テストからデータセットの部分をこちらに移行します。

tests/Datasets/LoginData.php

dataset('invalidLoginData', [
    '間違ったパスワード'    => ['test@example.com', 'wrong-password'],
    '間違ったメールアドレス' => ['wrong@example.com', 'password'],
]);

データセット名はinvalidLoginDataとしました。

元のテストコードの方は、with()の引数にデータセット名であるinvalidLoginDataを渡してあげればOKです。

test('users cannot authenticate with invalid credentials', function (string $email, string $password) {
・・・
})->with('invalidLoginData');

まとめ

このプラグインを使っても劇的にテストコードが短くなる訳ではなく、「少し良くなる」というものなので、すでにテストの書き方が確立されている環境にわざわざインストールする必要はなさそうです。が、Laravelの開発コアメンバーが開発しているプラグインなので、新しいプロジェクトでPestのテストを書いてゆくという場合には導入してみるのも面白そうだなと感じました。

PHPUnit 11 - アノテーションからアトリビュートに書き換える

Mon, 06 Jan 2025 02:32:20 +0900

PHPUnit11でテストを実行すると、実行後の出力に「PHPUnit Deprecations」というメッセージが表示されるようになっていました。@testなどの慣れ親しんだアノテーションはPHPUnit12からサポート外となるようですので、新しいアトリビュートへ変更します。

PHPUnit12で削除される@アノテーション

OK, but there were issues!
Tests: 28, Assertions: 64, PHPUnit Deprecations: 1.

こちらがテスト時に表示されたメッセージです。「PHPUnit Deprecations: 1」だけだと分かりにくいので、詳細内容も出力されるようにphpunit.xmlを少し修正します。

phpunit.xml

...
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true"
         displayDetailsOnPhpunitDeprecations="true" //これを追加
>
...

phpunitタグにdisplayDetailsOnPhpunitDeprecations=“true”を追加しました。これで再度テストを実行すると、以下のようなメッセージが出力されました。

There was 1 PHPUnit test runner deprecation:

1) Metadata found in doc-comment for method Tests\Unit\Models\UserModelTest::is_admin_check(). Metadata in doc-comments is deprecated and will no longer be supported in PHPUnit 12. Update your test code to use attributes instead.

メッセージによると、ドキュメントコメント内のアノテーションは非推奨とのこと。PHPUnit12ではサポート対象外となるため、テストのアノテーションは「アトリビュート」に書き換える必要があるようです。

アノテーション → アトリビュートの書き換え

今まで使っていたアノテーションの記述は、アトリビュートでは以下のように書き換えます。

@test → #[Test]
@dataProvider → #[DataProvider('データプロバイダ名')]
@covers → #[CoversMethod('カバー対象のクラス', 'カバー対象メソッド')]

他のアトリビュートの記述はドキュメントで紹介されていますのでご参照ください。

基本的にはこれらを書き換えればいいだけなのですが、@coversに関しては記述の位置が大きく変更となるためご注意ください。では具体的にどう変更になったか?というのを、以下のテストコードを使ってご紹介します。

変更前のテスト（アノテーション使用）

こちらがアノテーションを使用したユニットテストです。ドキュメントコメント内に@test、@covers、@dataProviderを使用しています。

namespace Tests\Unit\Models;

use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class UserModelTest extends TestCase
{
    use RefreshDatabase;

    /**
     * @test
     * @covers App\Models\User::isAdmin
     * @dataProvider roleDataProvider
     */
    public function is_admin_check(string $role, bool $expected): void
    {
        $user = User::factory()->create(['role' => $role]);

        $this->assertEquals($expected, $user->isAdmin());
    }

    public static function roleDataProvider(): array
    {
        return [
            'role = admin' => [
                'role' => 'admin',
                'expected' => true
            ],
            'role = user' => [
                'role' => 'user',
                'expected' => false
            ],
            'role = role' => [
                'role' => 'editor',
                'expected' => false
            ],
        ];
    }
}

変更後のテスト（アトリビュート使用）

以下が、アトリビュートに書き換えた後のテストになります。

namespace Tests\Unit\Models;

use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use PHPUnit\Framework\Attributes\CoversMethod;
use PHPUnit\Framework\Attributes\DataProvider;
use PHPUnit\Framework\Attributes\Test;
use Tests\TestCase;

#[CoversMethod(User::class, 'isAdmin')]
class UserModelTest extends TestCase
{
    use RefreshDatabase;

    #[Test]
    #[DataProvider('roleDataProvider')]
    public function test_is_admin_check(string $role, bool $expected): void
    {
        $user = User::factory()->create(['role' => $role]);

        $this->assertEquals($expected, $user->isAdmin());
    }

    public static function roleDataProvider(): array
    {
        return [
            'role = admin' => [
                'role' => 'admin',
                'expected' => true
            ],
            'role = user' => [
                'role' => 'user',
                'expected' => false
            ],
            'role = role' => [
                'role' => 'editor',
                'expected' => false
            ],
        ];
    }
}

まず、useで#[Test]などの各属性に対応するクラスをインポートする必要があります。そして、#[Test]・#[DataProvider()]はアノテーションと同様テストケースの直前に配置します。

一番大きな変更である@coversの位置ですが、アトリビュートではクラス宣言の直前に置く形になります。ドキュメントにもあるように、#[CoversMethod()]は各テストケースではなくテストクラスに指定する必要があります。

最初このルールに気が付かず、@coversと同じように各テストケースの前に#[CoversMethod()]を配置したところ以下のようなエラーが発生しテスト失敗となりました。

$ ./vendor/bin/phpunit

An error occurred inside PHPUnit.

Message:  Attribute "PHPUnit\Framework\Attributes\CoversMethod" cannot target method (allowed targets: class)

ちゃんとエラーが出てくれたので、気がつけてよかったです。

改めてテストを実行

アトリビュートへの書き換えが正しくできているか、再度テストを実行してみます。

$ ./vendor/bin/phpunit

OK (28 tests, 64 assertions)

Deprecationsのメッセージが出なくなりました。テスト数やアサーションの数も同じなので、書き換えは問題なくできたようです。

カバレッジの出力を確認

#[CoversMethod()]の動作確認も兼ねて、カバレッジの出力も見てみます。私の環境ではpcovを使用しています。まだの方はインストールと、php.iniにて以下を設定ください。

php.ini

extension=/path/to/your/pcov.so
pcov.enabled=1
pcov.directory=/path/to/your/project

では、カバレッジのオプションをつけてテストを実行します。

$ ./vendor/bin/phpunit --coverage-html coverage

実行後、プロジェクトルートのcoverageディレクトリにhtmlファイルが生成され、#[CoversMethod]で指定した関数もちゃんとカバレッジが計測されていました。

Laravel Pestでモック・例外のテスト

Wed, 04 Dec 2024 07:44:19 +0900

前回の記事では、LaravelプロジェクトのPHPUnitテストをプラグインを使ってPestへ自動変換しましたが、今回は自分でPestのテストを作成します。外部APIのモック、基本的なアサーションや例外が投げられたパターンなどのテストです。

テスト対象

以下が今回のテスト対象であるTestClassです。getTranslate()では引数のテキストをAPIを使って翻訳し、結果をJsonレスポンスで返却。処理に失敗した場合は例外をスローするようになっています。

ラップしているTranslationApiは外部APIなので、今回はこちらはモックとします。

class TestClass
{
    public function __construct(
        private readonly TranslationApi $translator //これをモックする
    ) {}

    public function getTranslate(string $content): JsonResponse
    {
        try {
            $translatedContent = $this->translator->translate(
                $content
            );

            return response()->json([
                'status'  => 'success',
                'message' => '操作が成功しました。',
                'data'    => $translatedContent,
            ]);

        } catch (Exception $e) {

            throw new Exception('翻訳に失敗しました: '.$e->getMessage());
        }
    }
}

Pestの構文

Pestの構文は以下のようになっており、テストをグルーピングするdescribe()メソッドと、１つ１つのテストケースを指すtest()もしくはit()メソッドで構成されています。PHPUnitで書かれているクラス宣言は不要です。

describe('グループ名', function () {
   test('テスト１', function () {
       //テスト内容
    });
 
   it('テスト２', function () {
       //テスト内容
    });
});

describe()の使用は任意なので、最小構成のtest()、it()のみで問題ありません。

またtest()とit()のどちらを使うのかという点ですが、テストの動作自体は同じなのでどちらでも大丈夫です。ただit()を使った場合、実行結果の出力で以下のようにテスト名の前にitがつくようになっています。

共通処理

ではテストを書いてゆきます。今回は成功・失敗の２パターンテストを書きますので、共通の処理をbeforeEach()を使ってまとめておきます。beforeEach()は各テストケースの実行前に呼び出される、PHPUnitのsetUp()と同じような役割です。

モック対象であるTranslationApiのモック化と、テスト対象クラスのインスタンス化の２点を以下のように共通処理としました。

beforeEach(function () {
    // モックを作成
    $this->mock = Mockery::mock(TranslationApi::class);

    // テスト対象のクラスをインスタンス化
    $this->service = new testClass($this->mock);
});

モックにはPHPUnitと同様にMockeryを使用します。ここではmock()メソッドで対象クラスをモック化するのみとして、モックの振る舞いは各テスト内でセットします。

testClassクラスのインスタンス化も、PHPUnitと記述は特に変わりません。

なお$this->mockや$this->serviceのプロパティ宣言は、Pestでは不要です。

成功パターンのテスト

「翻訳が成功して期待するレスポンスが返ってきたケース」のテストコードは以下になります。

test('翻訳 成功', function () {
    //準備
    $content = 'こんにちは';
    $expected = 'Hello';

    $this->mock
        ->shouldReceive('translate')
        ->once()
        ->with($content)
        ->andReturn($expected);

    //テスト実行
    $response = $this->testClass->getTranslate($content);

    expect($response->getData(true))
        ->toMatchArray([
            'status'  => 'success',
            'message' => '操作が成功しました。',
            'data'    => 'Hello',
        ]);
});

テストコードは大きく前半の準備部分と、後半の実行・アサーションの部分に分かれています。

まず前半では、モックの振る舞いを定義しています。shouldReceive(’translate’)は、translateメソッドが呼ばれること、once()は、呼ばれるのは１度だけという回数を、with($content)で渡される引数を、そして最後にandReturn()で、戻り値を指定しています。

次に後半の、テスト実行と戻り値のアサーションです。

受け取った$response自体はJsonResponseオブジェクトなので、$response->getData(true)でテストに必要な値だけを取り出しています。getData()はデフォルトでstdClassオブジェクトを返すので、ここでは引数にtrueを渡すことで配列として戻り値を受け取っています。

そして検証にはexpect()というPestのアサーションメソッドを使用します。expect()はそれ単体で使用することはなく、通常他のアサーション関数をチェーンします。今回はtoMatchArray()という配列比較の関数を繋ぎました。

toMatchArray()は上のテストコードのように全ての項目を比較することもできますし、以下のように、一部の項目だけといった部分一致も検証できるのでとても便利です。

    expect($response->getData(true))
        ->toMatchArray([
            'message' => '操作が成功しました。',
            'data'    => 'Hello',
        ]);

    expect($response->getData(true))
        ->toMatchArray([
            'data'    => 'Hello',
        ]);

また以下は配列比較でテストが失敗した場合のスクリーンショットですが、差分をこのようにわかりやすく出力してくれます。

失敗パターンのテスト

では次は、「翻訳が失敗し、例外を返すパターン」のテストコードです。

test('翻訳 失敗で例外が返る', function () {

    $content = 'こんにちは';
    $errorMessage = 'API error occurred';

    $this->mock
        ->shouldReceive('translate')
        ->once()
        ->with($content)
        ->andThrow(new Exception($errorMessage));

    $this->testClass->getTranslate($content);

})->throws(Exception::class, '翻訳に失敗しました: API error occurred');

先ほどの成功のテストとは少し構成が変わりました。

まずは前半のモック定義部分。ここは先ほどとほとんど同じですが、モックの戻り値の指定にandThrow(new Exception($errorMessage))として、例外を投げるように指定しています。

そして検証部分はチェーンで繋いだthrows()メソッドで行います。throws()はPestが提供しているメソッドで、第一引数に期待する例外クラスを、第二引数では例外のメッセージを渡します。

PHPUnitの場合、例外の検証時は以下のようにテストコードの冒頭に置かなければいけません。一方Pestではテスト実行後の最後にアサーションを配置できるので、テスト実行の流れと合っていてとても読みやすいと感じました。

public function test_翻訳失敗_PHPUnitの場合()
{
    $this->expectException(Exception::class);
    $this->expectExceptionMessage('翻訳に失敗しました: API error occurred');
    // ... 以下でテスト実行
}

現在LaravelでPHPUnitを使っていてPestを導入しようかなと考えている方は、よろしければ以下の移行手順もご覧ください。

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

Sun, 10 Nov 2024 01:38:41 +0900

Laravel10から公式にテストフレームワークとしておすすめされるようになったPestですが、すでにPHPUnitで作成したテストファイルがたくさんある場合、それらを書き換えての移行は大変です。そこで、Pestが提供している変換用プラグインpestphp/pest-plugin-driftを試してみました。

Pest変換対象のLaravelプロジェクト

今回Pestへ変換するLaravelプロジェクトは以下の環境です。テスト用の小さいプロジェクトなので、テストファイルは9ファイルのみとなっています。

Laravel Framework 11.29.0 PHPUnit 11.4.2 PHP 8.2.24

Pest・Pest変換用プラグインインストール

では早速Pestからインストールします。Pest公式サイトの手順に従って進めます。

まずはPHPunitを削除。

$ composer remove phpunit/phpunit

次に、以下のコマンドでPestをインストール。

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

Pestのバージョン3.5がインストールされました。続いてinitを実行します。

$ ./vendor/bin/pest --init

すると以下のファイルが作成されました。すでに存在しているファイルはパスされるので、実質Pest.phpのみが作成された形です。

これでPest本体のインストールは完了です。テストファイルの記述はまだPHPUnitのままですが、この段階でも./vendor/bin/pestが実行できます。

続いて変換用プラグインをインストールしてゆきます。こちらも公式サイトの手順に従って、以下のコマンドを実行します。

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

バージョン3.0.0がインストールされました。最後に、以下のコマンドでPHPUnitからPestへの変換を実行します。

$ ./vendor/bin/pest --drift

既存のテストファイルが全て変換されました。

今回は小さいシンプルなプロジェクトなので各種インストールはとくに問題なく進みましたが、大きなプロジェクトの場合依存関係の問題でインストールがスムーズにいかないこともあると思います。

PHPUnit → Pest変換前後の比較

では、変換されたファイルを前後比較してみます。まず、以下が変換前のPHPUnit仕様のテストです。setUpやdataProviderも使用したよくあるテストコードです。

/tests/Feature/Auth/AuthenticationTest.php

namespace Tests\Feature\Auth;

use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class AuthenticationTest extends TestCase
{
    use RefreshDatabase;

    protected $user;

    protected function setUp(): void
    {
        parent::setUp();

        // 共通ユーザー作成
        $this->user = User::factory()->create([
            'email'    => 'test@example.com',
            'password' => 'password'
        ]); 
    }

    /**
     * @covers \App\Http\Controllers\Auth\LoginController::showLoginForm
     */
    public function test_login_screen_can_be_rendered(): void
    {
        $response = $this->get('/login');
        $response->assertStatus(200);
    }

    /**
     * @covers \App\Http\Controllers\Auth\LoginController::login
     */
    public function test_users_can_authenticate_with_valid_credentials(): void
    {
        $response = $this->post('/login', [
            'email'    => 'test@example.com',
            'password' => 'password',
        ]);

        $this->assertAuthenticated();
        $this->assertEquals('test@example.com', auth()->user()->email);
        
        $response->assertRedirect(route('dashboard', absolute: false));
    }

    /**
     * @covers \App\Http\Controllers\Auth\LoginController::login
     * @dataProvider invalidLoginDataProvider
     */
    public function test_users_cannot_authenticate_with_invalid_credentials($email, $password): void
    {
        $response = $this->post('/login', [
            'email'    => $email,
            'password' => $password,
        ]);

        $this->assertGuest();
        $response->assertStatus(302);
    }

    public static function invalidLoginDataProvider(): array
    {
        return [
            '間違ったパスワード'    => ['test@example.com', 'wrong-password'],
            '間違ったメールアドレス' => ['wrong@example.com', 'password'],
        ];
    }

    /**
     * @covers \App\Http\Controllers\Auth\LoginController::logout
     */
    public function test_users_can_logout(): void
    {
        $response = $this->actingAs($this->user)->post('/logout');

        $this->assertGuest();
        $response->assertRedirect('/');
    }
}

そして、Pestに変換された後のテストがこちらです。

/tests/Feature/Auth/AuthenticationTest.php

use App\Models\User;

uses(\Illuminate\Foundation\Testing\RefreshDatabase::class);

beforeEach(function () {
    // 共通ユーザー作成
    $this->user = User::factory()->create([
        'email'    => 'test@example.com',
        'password' => 'password'
    ]);
});

test('login screen can be rendered', function () {
    $response = $this->get('/login');
    $response->assertStatus(200);
});

test('users can authenticate with valid credentials', function () {
    $response = $this->post('/login', [
        'email'    => 'test@example.com',
        'password' => 'password',
    ]);

    $this->assertAuthenticated();
    expect(auth()->user()->email)->toEqual('test@example.com');

    $response->assertRedirect(route('dashboard', absolute: false));
});

test('users cannot authenticate with invalid credentials', function ($email, $password) {
    $response = $this->post('/login', [
        'email'    => $email,
        'password' => $password,
    ]);

    $this->assertGuest();
    $response->assertStatus(302);
})->with('invalidLoginDataProvider');

dataset('invalidLoginDataProvider', function () {
    return [
        '間違ったパスワード'    => ['test@example.com', 'wrong-password'],
        '間違ったメールアドレス' => ['wrong@example.com', 'password'],
    ];
});

test('users can logout', function () {
    $response = $this->actingAs($this->user)->post('/logout');

    $this->assertGuest();
    $response->assertRedirect('/');
});

変換後のPest仕様のコードではクラスの定義は削除され、それぞれのテストケースは関数宣言ではなくtest()関数として記述されています。また変換前は85行あったテストコードがPest変換後は57行とかなりコンパクトになりました。Docコメントが全て削除されているのが大きいのかもしれません。

それでは、移行するにあたり気になっていた箇所をピックアップしてみてみます。

dataprovider

PHPUnitのdataProviderは、Pest変換後は以下のようになりました。Docコメントとともに@dataProviderの記述は削除されて、代わりにwith()でデータセットを紐付けしています。テストとデータセットがバラバラなので、見た目にはPHPUnitとあまり変わりがありませんね。

test('users cannot authenticate with invalid credentials', function ($email, $password) {
・・・・・
})->with('invalidLoginDataProvider');

dataset('invalidLoginDataProvider', function () {
    return [
        '間違ったパスワード'    => ['test@example.com', 'wrong-password'],
        '間違ったメールアドレス' => ['wrong@example.com', 'password'],
    ];
});

データセットの紐付けは、以下のようにwith()内に記述される形に変換されることを期待したのですが、そうはなりませんでした。

test('users cannot authenticate with invalid credentials', function ($email, $password) {
    ・・・・・
    })->with([
        ['test@example.com', 'wrong-password'],
        ['wrong@example.com', 'password']
]);

setUp関連

PHPUnitのsetUp()は、以下のようにbeforeEach()に変換されました。beforeEach()とは、それぞれのテストメソッドの実行前に毎回呼び出されるsetUp()と同じように共通の処理を行う際に使用されるメソッドです。

beforeEach(function () {
    // 共通ユーザー作成
    $this->user = User::factory()->create([
        'email'    => 'test@example.com',
        'password' => 'password'
    ]);
});

他にも、PHPUnitで当然のように書いていたparent::setUp()やuse RefreshDatabase;はPestでは書く必要がなく、またprotected $user;といったプロパティ宣言も不要です。Pestの謳い文句の通り、テストコードはだいぶシンプルにできますね。

テスト実行

では変換後のテストを実行してみましょう。

テストはコマンドラインで、

$ ./vendor/bin/pest

あるいは、

$ php artisan test

で実行できます。

以下のようにオプションを渡して実行ファイルを指定することもできます。

$ ./vendor/bin/pest --filter=AuthenticationTest //ファイル名を指定する場合

実行結果は以下のように出力されました。

テストにかかる時間はPestに変換しても速くなるということは特になく、PHPUnitと変わりなかったです。

今回は自動で変換したためPestの記述に関しては要点のみとなりましたが、次回は手動でPestのテストコードを作成してゆきます。

CypressでE2Eテストを自動化（５）laracasts/cypressでLaravelプロジェクトをテスト

Wed, 09 Oct 2024 12:42:04 +0900

ここまで４回の投稿でCypressテストの設定・テストコードなどをご紹介してきました。５回目の今回は、laracasts/cypressというLaravelでCypressを使用するために作成されたパッケージをご紹介します。Laravel10.xのプロジェクトにインストールして使ってみました。

Cypressのセットアップや基本的なテストなど、以前の記事は以下からご覧いただけます。

Cypressセットアップ・実行方法 Cypress画面表示のテスト Cypressログイン・ログアウトのテスト Cypressパスワードリセットのテスト

laracasts/cypressインストール

今までご紹介したCypressのテストでは、テスト対象プロジェクトとCypressが全く別のディレクトリでも問題なかったのですが、今回ご紹介するlaracasts/cypressはLaravelのartisanコマンドやfactoryなどを使用するため、テスト対象のLaravelプロジェクト内にインストールする必要があります。

ではまずはCypressをインストールします。Laravelのプロジェクトルートで、以下のコマンドを実行します。

% npm install cypress --save-dev

執筆時点で、cypress13.14.2がインストールされました。次にlaracasts/cypressのインストールです。以下のコマンドを実行します。

% composer require laracasts/cypress --dev

このコマンドで、laracasts/cypress3.0.2と関連パッケージがインストールされました。

最後に、以下のコマンドで初期ファイルを作成します。コマンドを実行するとcypressのディレクトリをどこに作成するか？を質問されるので、任意のディレクトリを指定してください。ここではコマンドラインで提案された通りのtests/配下を指定しました。

% php artisan cypress:boilerplate

Where should we put the cypress directory? [tests/cypress]:
> 


Updated tests/cypress/support/index.js
Updated tests/cypress/plugins/index.js
Created tests/cypress/plugins/swap-env.js
Created tests/cypress/integration/example.cy.js
Created tests/cypress/support/laravel-commands.js
Created tests/cypress/support/laravel-routes.js
Created tests/cypress/support/assertions.js
Created tests/cypress/support/index.d.ts
Created cypress.config.js
Created .env.cypress

ファイルが作成されました、さっそくCypressを立ち上げてみます。以下のコマンドを実行してください。

% npx cypress open

ここで、require is not defined in ES module scopeというエラーが発生しました。

require is not defined の修正

Laravel10ではデフォルトでpackage.jsonに“type”: “module”が設定されているのですが、これとlaracasts/cypressで使用されているCommonJS形式の記述がマッチしないことが原因でエラーとなっているようです。

このエラーの修正方法には何パターンかありますが、ここではLaravelのデフォルトを変更せず、またできるだけ簡単にエラーを解消できるよう以下の修正を行います。

１：ファイルの拡張子を.cjsに変更

まず、Cypress実行の際にrequireされる以下の２ファイルの拡張子を.jsから.cjsへ変更します。

/cypress.config.cjs                  // .jsから.cjsへ
/tests/cypress/plugins/swap-env.cjs  // .jsから.cjsへ

２：configファイルを修正

次に、cypress.config.cjsファイルのe2e内、setupNodeEvents()に以下のtaskを追加します。

cypress.config.cjs

const { defineConfig } = require('cypress')

module.exports = defineConfig({
.....

    e2e: {
        setupNodeEvents(on, config) {
          // ここにtaskを追加（plugins/index.jsの内容を移動）
          on('task', require('./tests/cypress/plugins/swap-env.cjs'));  //ここを追加
          return config　　　　　　　　　　　　　　　　　　　　　　　　　　　　  //ここを追加
        },
.....
    },
})

３：index.jsを削除

２の変更により/tests/cypress/plugins/index.jsは不要になるので削除します。

ここまででエラー修正は完了です。

４：baseUrlの指定

configファイルを開いているので、テストの実行に必要なbaseUrlも設定しておきましょう。同じくconfigファイルのe2e内にLaravelプロジェクトのURLをセットします。

cypress.config.cjs

const { defineConfig } = require('cypress')

module.exports = defineConfig({
.....

    e2e: {
        setupNodeEvents(on, config) {
          // return require('./tests/cypress/plugins/index.js')(on, config)
          // ここに元のplugins/index.jsの内容を移動
          on('task', require('./tests/cypress/plugins/swap-env.cjs'));
          return config
        },
        baseUrl: 'http://127.0.0.1:8000', //プロジェクトURLの指定
.....
    },
})

ここまで進めたら、再度以下のコマンドでCypressを立ち上げます。

% npx cypress open

問題なく起動したらダッシュボードを開いて、laracasts/cypressインストール時に自動生成されたexample.cy.jsを選択し、実行してみます。

こちらもエラーなく成功したら準備は完了です。

laracasts/cypressのコマンド

laracasts/cypressでは、Laravelプロジェクトのテストに便利なコマンドが用意されています。その中からいくつかテストでよく使うものをご紹介します。

まずはcreate()から。factoyと連動して、テスト用データを作成できます。以下の例ではUserデータを作成しています。

    cy.create('App\\Models\\User', { 
        name: 'ユーザー名',
        email: 'login-test@example.com',
    });

次に、login()・logout()です。コマンド名の通りログイン・ログアウトの処理を実行するコマンドで、PHPUnitでauth()->login($user)、auth()->logout()と記述した時と同じ動作をしてくれます。以下のように、引数にユーザーの情報を渡して使用します。

    cy.login({ name: 'ユーザー名' });
    cy.logout({ email: 'test@example.com'' });

そして次はcurrentUser()です。これはLaravelのauth()->user()と同じく、現在認証されているユーザーを取得してくれます。取得したユーザー情報は、Cypressコマンドのits()と組み合わせることで任意のプロパティが取り出せます。以下の例では取得したユーザーのemailデータを取り出し、期待通りか確認しています。

    cy.currentUser().its('email').should('eq', 'test@example.com');

最後に、refreshDatabase()です。Laravelのmigrate:refreshをコールします。このコマンドは任意の場所で使用できますが、CypressのbeforeEach()コマンドと組み合わせて使用すると、各テストケースの前にDBをリフレッシュしてくれるので便利です。

    beforeEach(() => {
        cy.refreshDatabase();
    });

テストコード

今回は新規会員登録・ログイン・ログアウトのテストを、ここまでご紹介したlaracasts/cypressのコマンドを使用して作成しました。

LaracastsCypressTest.cy.js

describe('laracasts/cypress Test', () => {

    beforeEach(() => {
        cy.refreshDatabase();
    });

    it('新規会員登録テスト', () => {
        cy.visit('/register');

        // フォームに情報を入力・送信
        cy.get('input[name=name]').type('新規登録ユーザー');
        cy.get('input[name=email]').type('test@example.com');
        cy.get('input[name=password]').type('password');
        cy.get('input[name=password_confirmation]').type('password');
        cy.get('button[type="submit"]').click()

        // ダッシュボードにリダイレクトされたことを確認
        cy.url().should('eq', Cypress.config().baseUrl + '/dashboard');
        // 認証中のユーザーを確認
        cy.currentUser().its('name').should('eq', '新規登録ユーザー');
    });

    it('ログインテスト', () => {
        // ユーザーを作成
        cy.create('App\\Models\\User', {
            name: 'ログインテスト',
            email: 'login-test@example.com',
        });

        cy.visit('/login');
        cy.get('input[name=email]').type('login-test@example.com');
        cy.get('input[name=password]').type('password');
        cy.get('button[type="submit"]').click()

        // ダッシュボードに遷移したことを確認
        cy.url().should('eq', Cypress.config().baseUrl + '/dashboard');
        // 認証中のユーザーを確認
        cy.currentUser().its('email').should('eq', 'login-test@example.com');
    });

    it('ログアウトテスト', () => {
        // ユーザーを作成
        cy.create('App\\Models\\User', {
            name: 'ログアウトテスト',
            email: 'logout-test@example.com',
        });

        //ログインを実行
        cy.login({ name: 'ログアウトテスト' });
        cy.visit('/dashboard')

        //ドロップダウンメニューを開くためのボタンクリック・ログアウトボタンをクリック
        cy.get('.relative').click()
        cy.contains('a', 'ログアウト').click()

        cy.visit('/dashboard').assertRedirect('/login');
        // 認証中のユーザーがいないことを確認
        cy.currentUser().should('not.exist');
    });
});

では、テストを実行してみましょう。Cypressのブラウザでテストファイルをクリックします。まだCypressを立ち上げていない場合はnpx cypress openを実行してCypressを立ち上げてくださいね。

全て成功しました！今回Cypressコマンドの説明は省きましたが、以下の記事で実行方法や代表的なコマンドをご紹介していますのでぜひご覧ください。

Cypressセットアップ・実行方法 Cypress画面表示のテスト Cypressログイン・ログアウトのテスト Cypressパスワードリセットのテスト

CypressでE2Eテストを自動化（４）パスワードリセットのテスト

Tue, 03 Sep 2024 23:36:11 +0900

今回はパスワードリセットのテストです。リセットリンクをクリックしてメールアドレスを入力、MailHogに届いたメールの確認、パスワードリセット実行、という一連のユーザーの操作をCypress13.xで実装します。

Cypressのセットアップや画面表示テストなど、以前の記事は以下からご覧いただけます。

Cypressセットアップ・実行方法 Cypress画面表示のテスト Cypressログイン・ログアウトのテスト

Cypressでパスワード再設定のテスト

引き続きLaravel Breezeのログイン画面を使ってテストします。テストの流れは、少し項目が多いですが以下のような形で進めようと思います。

ログイン画面で「パスワードを忘れた？」というリンクをクリック
パスワードリセットのリクエスト画面でメールアドレスを入力・送信
受信したメールのリンクからパスワードリセット画面へ遷移
パスワードリセットを実行
旧パスワードでログインが失敗することを確認
新しいパスワードでログインが成功することを確認

受信メールの確認にはMailHogを使用しますので、もしインストールがまだの場合は環境に合わせてインストールくださいね。

Laravelの.envは以下のように設定しています。

.env

...
MAIL_MAILER=smtp
MAIL_HOST=localhost
MAIL_PORT=1025
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null
MAIL_FROM_ADDRESS="local@example.com"
MAIL_FROM_NAME=メールテスト
...

事前準備１： cypress-mailhog

CypressからMailHogのデータを取得するための便利なコマンドが提供されているパッケージ、cypress-mailhogを使用します。

以下のコマンドでインストールできます。執筆時点で最新の2.4.0がインストールされました。

$ npm install --save-dev cypress-mailhog

また、以下の設定が必要です。まずはcypress/support/commands.jsファイルにインポート。

cypress/support/commands.js

import 'cypress-mailhog';
...

そして、cypress.config.jsファイルのenvにMailHogのURLを追記します。私の環境ではhttp://localhost:8025にてMailHogのUIが確認できます。

cypress.config.js

import { defineConfig } from "cypress";

export default defineConfig({
  env: {
    mailHogUrl: "http://localhost:8025", // MailHogのURLをここに追記
  },
  e2e: {
    baseUrl: 'http://127.0.0.1:8000',
  },
});

これでCypressのテスト内でcypress-mailhogのコマンドが使用できるようになりました。

具体的には以下のように、cy.に続けてCypressコマンドのように使用できます。mhGetAllMails()はメールボックスのメールを最大50件取得するコマンドで、mhFirst()は、直前のコマンドで取得したメールから最初の１件を抽出するコマンドです。

cy.mhGetAllMails()            //メールを最大50件取得
cy.mhGetAllMails().mhFirst()  //メールの最初の１件を取得

事前準備２： mailparser

次に、mailparserをインストールします。今回は届いたメールの本文を確認する必要があるのですが、先ほどのcypress-mailhogで取得したメールの本文を見てみると、以下のようにテキストとして読めない状態です。

そのためmailparserを使用して、人間が読めるように解析する必要があります。

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

$ npm install mailparser --save-dev

こちらも2ファイルに設定が必要です。まずcypress/support/commands.jsにカスタムコマンドを追加します。先ほどインストールしたcypress-mailhogのimport文も含めると、以下のようになります。

cypress/support/commands.js

import 'cypress-mailhog'; // cypress-mailhog 用の記述
...
Cypress.Commands.add('mhParseMail', { prevSubject: true }, (mail) => {
  return cy.task('parse-mail', { mail: mail.Raw.Data })
})
...

カスタムコマンド名は任意ですが、mhParseMailとしました。

そして、cypress.config.jsにmailparserのimportとtaskを追加します。taskとは、テストコード内からブラウザ外で必要な作業を呼び出すための機能です。taskのドキュメントはこちら

先ほどcypress-mailhogで同ファイルに書き込んだものと合わせると、最終的には以下のようになります。

cypress.config.js

import { defineConfig } from "cypress";
import { simpleParser as parser } from 'mailparser'; // ここでmailparserをインポート

export default defineConfig({
  env: {
    mailHogUrl: "http://localhost:8025"
  },
  e2e: {
    baseUrl: 'http://127.0.0.1:8000',
    setupNodeEvents(on, config) {                 // タスク用の追記ここから
      on('task', {
        'parse-mail': ({ mail }) => parser(mail), // タスクを定義
      })
    },                                            // タスク用の追記ここまで
  },
});

on(’task’, {…})がタスクを定義している箇所です。task名は任意ですが、ここではparse-mailとしました。カスタムコマンドmhParseMail()を実行するとparse-mailというtaskが呼ばれ、mailparserによりメール解析が実行される、という流れです。

ここまで設定できたらテストコードからの呼び出しは簡単で、cypress-mailhogで提供されているmhGetAllMails().mhFirst()に繋いで以下のように使用します。

cy.mhGetAllMails().mhFirst().mhParseMail().then((mail) => {
 mail.subject               // 件名を取得
 mail.from.value[0].address // Fromを取得
 mail.text                  // 本文を取得
}

取得したメールの１通目のデータをmhParseMail()で解析してからthen()に渡します。受け取ったmailオブジェクトはmailparserの形式になっているため、上の例のようにmail.subjectで件名を、mail.from.value[0].addressでメールのfromを、mail.textで本文を取得できます。

他にもプロパティが色々ありますのでmailparserのドキュメントをご確認ください。

wrap

ここまでで事前準備は完了ですが、最後に今回新しく使用するコマンドwrap()をご紹介します。

cypress-mailhogやmailparserから受け取ったメールデータはJavaScriptのオブジェクトです。このデータをCypressのアサーションコマンドで扱うために、以下のようにwrap()コマンドでラップします。

cy.mhGetAllMails().mhFirst().mhParseMail().then((mail) => {
 cy.wrap(mail.subject).should('eq', 'パスワードのリセット方法について');
}

これで、Cypressコマンドを繋いでメールの件名が期待した内容がどうかを検証できるようになります。

Cypressでパスワードリセットのテスト

以下がパスワードリセットのテストコード全文になります。

cypress/e2e/PasswordResetTest.cy.js

it('パスワードリセットのテスト', () => {

  cy.visit('/login');
  cy.contains('a', 'パスワードを忘れた').click();

  // パスワードリセットページに遷移したことを確認
  cy.url().should('include', '/forgot-password');

  // メールアドレス入力
  cy.get('input[name="email"]').type(Cypress.env('email'));

  // パスワードリセットメール送信ボタンをクリック
  cy.contains('button', 'パスワードリセットメールを送信').click();

  // 取得した一覧のうち、１件目（最新）のメール本文を取得
  cy.mhGetAllMails().mhFirst().mhParseMail().then((mail) => {

    cy.wrap(mail.subject).should('eq', 'パスワードのリセット方法について');
    cy.wrap(mail.from.value[0].address).should('eq', 'from@example.com');

    // メールの本文からパスワードリセットのためのリンクを抽出
    const hrefRegex = /https?:\/\/[^\s/"']+\/reset-password\/[^\s/"']+/;
    let match = hrefRegex.exec(mail.text)

    // パスワードリセットの画面へ遷移
    cy.visit(match[0])

    cy.get('input[name="email"]').type(Cypress.env('email')); // メールアドレス入力
    cy.get('input[name="password"]').type('new-password');    // 新しいパスワード
    cy.get('input[name="password_confirmation"]').type('new-password'); // パスワードの再入力

    // パスワードリセットメール送信ボタンをクリック
    cy.contains('button', 'パスワードのリセット').click();

    // ログイン画面へ遷移したことを確認
    cy.url().should('eq', Cypress.config().baseUrl + '/login');

    // 旧パスワードでログインすると失敗する
    cy.get('input[name="email"]').type(Cypress.env('email'));
    cy.get('input[name="password"]').type(Cypress.env('password'));
    cy.get('button[type="submit"]').click();

    cy.get('input[name="email"]')
      .next('ul')
      .should('contain', 'ログイン情報が存在しません。');

    // 新しいパスワードで再度ログイン試行（メールアドレスの入力値は残っているので不要）
    cy.get('input[name="password"]').type('new-password'); // 新しいパスワード
    cy.get('button[type="submit"]').click();

    // ダッシュボードに遷移したことを確認
    cy.url().should('eq', Cypress.config().baseUrl + '/dashboard');
  })
})

ではテストを実行してみます。npx cypress openでCypressを立ち上げて、対象ファイルをクリックします。

成功しました！ですが、このテストではDBのパスワードを変更してしまうため、どこかでパスワードをデフォルトに戻すなどの処理を行う必要があります。

CypressでDBをリセットするには、テスト対象のプロジェクトにDBリセット用のAPIを用意する、DBリセット用のシェルスクリプトを作成してテストから呼び出す・・・などの方法が考えられますが、今回はLaravelのプロジェクトがテスト対象ということもあり、ユニットテストのようにrefreshDatabase()が実行できれば便利ですよね。

ということで、次回はLaravelプロジェクトをCypressでテストするときに便利なパッケージをご紹介します。

参照

Cypressセットアップ・実行方法 Cypress画面表示のテスト Cypressログイン・ログアウトのテスト

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

Sun, 04 Aug 2024 06:19:43 +0900

前回のCypressでの画面表示テストに続き、今回はログイン・ログアウトのテストです。カスタムコマンドの作り方やHTTPリクエストの実行など、Cypressのテストに欠かせないアプローチが出てきますので参考になれば嬉しいです。

Cypressのセットアップや画面表示テストなど、以前の記事は以下からご覧いただけます。

Cypressセットアップ・実行方法 Cypress画面表示のテスト

フォーム入力・ボタンクリック

ログインのテストは前回に続きLaravel Breezeのログイン画面で行います。フォーム画面のテストには、テキスト入力・ボタンクリックの操作が必要ですので、それぞれCypressのtype()とclick()コマンドを使用します。

どちらのコマンドもcy.type()…のようにcyに直接繋げるのではなく、操作対象の要素を取得した後に繋いで使用します。例えばメールアドレス入力欄にメールアドレスを入力、またsubmitボタンをクリックといった操作は、以下のように記述します。

  cy.get('input[name="email"]').type('test@example.com')
  cy.get('button[type="submit"]').click()

cypress.env.jsonに環境変数をセット

ログイン情報など、テストの実行環境によって異なる値はcypress.env.jsonを作成してそちらにまとめておくと便利です。

今回使用するユーザーのメールアドレス・パスワードは、以下のように定義しました。

cypress.env.json

{
  "email": "test@example.com",
  "password": "password"
}

テストコードの中でこの値を呼び出すには、Cypress.env()を使います。

  cy.get('input[name="email"]').type(Cypress.env('email'));
  cy.get('input[name="password"]').type(Cypress.env('password'));

ログイン成功・失敗のテストコード

type()・click()を使用した、ユーザーがログインに成功するケースとエラーが発生するケースのテストコードは以下のようになります。アサーションは前回と同じくshould()を使って検証します。

it('正しいメールアドレス・パスワードでログイン成功', () => {

  cy.visit('/login')

  cy.get('input[name="email"]').type(Cypress.env('email'))
  cy.get('input[name="password"]').type(Cypress.env('password'))
  cy.get('button[type="submit"]').click()

  // ダッシュボードに遷移
  cy.url().should('eq', Cypress.config().baseUrl + '/dashboard')
})

it('パスワード間違いでログイン失敗', () => {

  cy.visit('/login')

  cy.get('input[name="email"]').type(Cypress.env('email'))
  cy.get('input[name="password"]').type('wrong-password') //間違ったパスワード
  cy.get('button[type="submit"]').click()

  //ログイン画面のまま
  cy.url().should('include', '/login')

  // 画面のエラー表示を確認
  cy.get('input[name="email"]')
    .next('ul')
    .should('contain', 'ログイン情報が存在しません。')
})

ログイン失敗のテストでは、「ログイン情報が存在しません。」のエラーメッセージが存在することを確認しています。このエラーメッセージはLaravel Breezeでは以下のHTMLで出力されます。

<input class="border-gray-300 focus:border-indigo-500 focus:ring-indigo-500 rounded-md shadow-sm block mt-1 w-full" id="email" type="email" name="email" value="test@example.com" required="required" autofocus="autofocus" autocomplete="username">
<ul class="text-sm text-red-600 space-y-1 mt-2">
    <li>ログイン情報が存在しません。</li>
</ul>

メッセージ出力箇所のul・liには要素特定に使えそうなidやclassが割り当てられていないため、input[name=“email”]要素の次のul要素内をチェックします。

request・thenコマンド

さて次はログアウトですが、テストを作成する前にrequest()とthen()コマンドをご紹介します。

request()は、HTTPリクエストを送信するために使用するコマンドです。以下のように記述すると、引数のURLに対してGETリクエストを送信します。

cy.request('/login')

POST送信の場合はオブジェクト形式でオプションを渡す必要があります。以下のように記述すると、POSTメソッドでURL/loginに対してリクエストを送信、かつリクエストbodyにはパスワード情報を含める。という意味になります。

    cy.request({
      method: 'POST',
      url: '/login',
      body: {
        password:'password',
      }
    })

では次にthen()コマンドです。then()は単独で使うのではなく他のコマンドにチェーンして、前のコマンドからの結果を受け取る形で記述します。具体的な使用方法として、先ほどのPOST送信にthen()を繋げました。

    cy.request({
      method: 'POST',
      url: '/login',
      body: {
        password:'password',
      }
    }).then((response) => {
      expect(response.status).to.eq(200)
    })

このコードでは、HTTPリクエストが完了するのを待ってから、そのレスポンスをresponseという引数で受け取ります。その後、コールバック関数内でレスポンスのステータスコードを検証しています。

then()は他にもHTML要素や任意の値やオブジェクトなども扱えます。詳しくはドキュメントをご参照ください。

ログアウトのテスト

ではログアウトのテストを作成してゆきましょう。画像のように、ドロップダウンを開いてログアウトリンクをクリックするとログアウトすることをテストします。

こういったログアウトのようなテストでは、ユーザーがすでにログインしている状態を準備する必要があります。これを、直接フォームに入力してボタンをクリックする方法で行なっても良いのですが、それでは画面操作の分余計な時間がかかってしまいます。

そこで、先ほどご紹介したrequest()を使用してHTTPリクエストでログインすることにします。これにより、UIを介さずに効率的にログイン処理を完了できます。

ログイン処理のカスタムコマンドを作成

テスト内で繰り返し使用する処理はカスタムコマンドとして定義します。これにより、どのテストからでも簡単に呼び出して使用できるようになります。

cypress/support/commands.jsファイルにカスタムコマンドを追加し、その際Cypressが定めた以下の構文を使用します。

Cypress.Commands.add('カスタムコマンド名', (引数) => { })

以下が作成したカスタムコマンドです。ユーザー画面のログインなのでコマンド名はloginAsUserとしました。

cypress/support/commands.js

Cypress.Commands.add('loginAsUser', (email, password) => {
  // Step 1: ログインページにアクセスしてCSRFトークンを取得
  cy.visit('/login')
  cy.get('input[name="_token"]').invoke('val').then((csrfToken) => {
    // Step 2: 取得したCSRFトークンを使用してログインリクエストを送信
    cy.request({
      method: 'POST',
      url: '/login',
      form: true, // フォームデータとして送信
      body: {
        email: email,
        password: password,
        _token: csrfToken  // CSRFトークンをリクエストに含める
      }
    }).then((response) => {
      // Step 3: ログインが成功したかステータスコードで確認
      expect(response.status).to.eq(200);
    });
  });
})

ログインするだけなのに少し長いコマンドになっていますが、内容は大きく以下の３ステップに分かれています。

ログインに必要なCSRFトークンを取得する処理
cy.requestを使用してログインリクエストを実行
ログイン成功のステータス確認

まず、ステップ１ではログイン画面へアクセスし、トークンのデータを含むHTML要素を取得。その要素に対しinvoke(‘val’)を使用し、トークンの値だけを抜き出しています。invoke(‘val’)とはjQueryのval()メソッドを呼び出すということを意味します。なぜjQueryが使えるのか?というと、これはCypressがjQueryを内包しているためこのような値の取得方法が可能になっています。

さて、こうして取得したトークンは次のHTTPリクエストで使用します。そのためthen()で繋ぎ、トークンをcsrfTokenとして受け取ります。

そしてステップ２は、request()でのHTTPリクエスト実行です。リクエストメソッド、URL、リクエストデータなどを引数に渡しています。_tokenとしてcsrfTokenも含まれていますね。

最後のステップ３はレスポンスの検証です。then()でレスポンスを受け取り、expect()を使ってHTTPステータスを確認しています。expect()はCypressが内部で使用しているChai.jsというアサーションライブラリのメソッドであるため、cy.に繋げず単独で使用できます。

コマンドが完成しました！これをテストの中では、以下のように呼び出して使います。

  cy.loginAsUser()

ログアウトのテストコード

カスタムコマンドを使用したログアウトのテストコードは以下のようになります。

it('ログアウトリンククリックでログアウト', () => {

  //カスタムコマンドでログイン
  cy.loginAsUser(Cypress.env('email'), Cypress.env('password'))

  //テスト対象画面へ遷移
  cy.visit('/dashboard')

  //ドロップダウンメニューを開くためのボタンクリック・ログアウトボタンをクリック
  cy.get('.relative').click()
  cy.contains('a', 'ログアウト').click()

  //ホーム画面へ遷移したことを確認
  cy.url().should('eq', Cypress.config().baseUrl + '/')
});

カスタムコマンドによるログイン処理、ログアウト実行、アサーション、という構成です。ログアウトテストに直接関係のないログイン処理を別ファイルに切り出しているので、テストコードがすっきりしていいですね。

では、ここまでのログイン成功・ログイン失敗・ログアウトのテストを全て実行してみます。

無事成功しました！次回は、Cypressでメール確認のテストを作成します。

参照

CypressでE2Eテストを自動化（１）セットアップ CypressでE2Eテストを自動化（２）画面表示のテスト

ユニットテストの超高速化

Wed, 17 Jul 2024 11:26:20 +0900

長年管理しているお客さんのプロジェクトのユニットテスの数が増えてきました。Featureテストも含めてテストケースの数は2,400以上あります。私の古めのWindowsのマシン（i7-9700CPU @ 3.00GHz）のWSL2環境では、7分51秒かかります。今回はこのテスト実行所有時間をほぼ1/10の50秒以下に縮めた話です。

mysqlをメモリー内で実行

DBを使用するテストが多いので最初に考えたのは、使用しているmysqlサーバーのエンジンをInnoDBからMemoryとすることです。しかしこれはすぐに不可能とわかりました。MemoryのエンジンではTEXTのデータタイプを対応していないからです。

どうしたらよいかといろいろ調査すると、mysqlのDBを保存しているボリュームをハードディスクのストレージからtmpfsに変えれば良いらしい。tmpfsは以下に説明されるようにメモリに存在するファイルシステムです。 tmpfsとは

しかし、ローカル環境（WSL2）で実行されているmysqlサーバーをtmpfsで走らせるとなると、mysqlサーバーがいろいろなプロジェクトで共有されているためにとても不都合であるし、マシンを落としたらそれでDB内のデータは消えてしまうとなるともっと困ります。

ということで、sailを使用してdocker内でmysqlサーバーをtmpfsで実行するのが理想となりました。

sailのセットアップに関してはここでは説明しませんが、セットアップの産物としてdocker-compose.ymlが作成されます。

このdocker-compose.ymlのmysqlサーバーの定義において、以下のようにvolumesのsail-mysqlをコメントアウトして、tmpfsを追加します。

...
    mysql:
        image: 'mysql/mysql-server:8.0'
        ports:
            - '${FORWARD_DB_PORT:-3306}:3306'
        environment:
            MYSQL_ROOT_PASSWORD: '${DB_PASSWORD}'
            MYSQL_ROOT_HOST: '%'
            MYSQL_DATABASE: '${DB_DATABASE}'
            MYSQL_USER: '${DB_USERNAME}'
            MYSQL_PASSWORD: '${DB_PASSWORD}'
            MYSQL_ALLOW_EMPTY_PASSWORD: 1
        volumes:
            # - 'sail-mysql:/var/lib/mysql' # コメントアウト！
            - './vendor/laravel/sail/database/mysql/create-testing-database.sh:/docker-entrypoint-initdb.d/10-create-testing-database.sh'
        tmpfs: # ここを追加！
            - /var/lib/mysql
        networks:
            - sail
        healthcheck:
            test:
                - CMD
                - mysqladmin
                - ping
                - '-p${DB_PASSWORD}'
            retries: 3
            timeout: 5s
...

以下を実行して、

$ sail up

dockerを立ち上げて、docker内のmysqlサーバーのファイルシステムを見ると、

sh-4.4# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         251G   26G  213G  11% /
tmpfs            64M     0   64M   0% /dev
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
shm              64M     0   64M   0% /dev/shm
/dev/sdd        251G   25G  214G  11% /docker-entrypoint-initdb.d/10-create-testing-database.sh
/dev/sde        251G   26G  213G  11% /etc/hosts
tmpfs           7.8G  199M  7.6G   3% /var/lib/mysql
tmpfs           7.8G     0  7.8G   0% /proc/acpi
tmpfs           7.8G     0  7.8G   0% /sys/firmware

/var/lib/mysqlがtmpfsとなっていますね。

テストを実行してみましょう。

$ sail artisan test

テスト実行の所有時間は、7分51秒から219秒から3分39秒と一気に半分以下となりました。

並行処理でテストを実行

今度は、パラレルテストを利用してもっと高速化してみましょう。

まず、必要なライブラリをインストールします。

$ sail composer require brianium/paratest --dev

その後、パラレルテストを実行します。

$ sail artisan test --parallel

tmpfsとパラレルを組み合わせたテスト実行となり、その結果、所有時間は驚異の49秒となりました。ほぼ1/10の時間です。

Docker内のmysqlサーバーでデータベースを閲覧すると、以下のように、testingのデータベース７個新たに作成ｓれて、計８個となっています。これは私のマシンが８コアのためです。パラレルテストは使用のマシンのコア数でデータベースの数が決まります。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| laravel            |
| mysql              |
| performance_schema |
| sys                |
| testing            |
| testing_test_1     |
| testing_test_2     |
| testing_test_3     |
| testing_test_4     |
| testing_test_5     |
| testing_test_6     |
| testing_test_7     |
+--------------------+

ちなみに、tmpfsなしのパラレルテストの所要時間は、5分28秒でした。tmpfs + parallelが最速のチームということですね。

CypressでE2Eテストを自動化（２）画面表示のテスト

Wed, 03 Jul 2024 12:59:35 +0900

テスト自動化ツールCypressのセットアップに続いて、今回は画面表示のテストです。Cypressでの画面遷移や要素の取得、アサーションなど基本的な書き方をご紹介します。

Cypressの構文

Cypressの基本的な構文は、以下のように３つのグループに分かれています。describeとcontextはテストケースのグループを、itは１つ１つのテストケースを表しています。

contextはdescribeのエイリアスなので、機能は同じです。テストケースの大まかな定義や特定の条件でのグループ分けなど、テストのスタイルによって使い分けることができます。

describe('大項目', () => {
  context('中項目', () {
    it('テスト１', () => {
      //テストの内容
    })

    it('テスト２', () => {
      //テストの内容
    })
  })
})

テストを作成する際にこれらの３つの項目全てが必要ということはなく、最小単位であるitだけでテストを構成しても問題ありません。

Cypressの画面遷移・要素の取得

今回のテスト対象はLaravel Breezeのログイン画面です。

・画面が表示できるか・ダッシュボードにアクセスするとログイン画面にリダイレクトされるか

をテストします。

これらのテストに必要なCypressのコマンドについて、１つずつ進めてゆきましょう。

まずは画面遷移から。visit()コマンドを使用します。引数にアクセスしたいURL（ここではローカルのログイン画面のURL）を渡して以下のように記述します。

      cy.visit('http://127.0.0.1:8000/login')

最初にcy.とありますが、Cypressではこのようにcy.の後にメソッドを繋げて記述します。

テスト対象画面に遷移できたら、次はメールアドレス入力欄やログインボタンの要素を取得します。画面の要素を取得するには、get()やcontains()を使用して以下のように書きます。

      cy.get('input#email')
      cy.get('button[type="submit"]').contains('ログイン')

get()の引数には取得したい要素のセレクタを渡します。上の例ではidが"email"であるinput要素、typeが"submit"であるbutton要素を指定しています。

そしてcontains()は、対象のテキストを「含む」要素を取得します。上記の例では、まずget()でtypeが"submit"であるbutton要素を取得し、contains()をチェーンで繋いで"ログイン"というテキストが含まれる要素に絞り込んでいます。「含む」なのでもし"ログインする"などの他のテキストが含まれていても取得対象となります。

CSSセレクタの指定については「○番目の要素」や「○というデータ属性」などの細かい指定も可能です。ドキュメントには色々な例が載っていますのでご参照ください。

また、URLの確認もテストではよくあるかと思いますが、こちらもコマンドが用意されています。

      cy.url()

これだけで、現在のURLを文字列として取得してくれます。

Cypressのアサーション

ここまででテスト対象の要素は取得できたので、検証に進みます。get()やcontains()の後にshould()をチェーンで繋ぎます。

      cy.get('input#email').should('exist')
      cy.get('button[type="submit"]').contains('ログイン').should('exist')

should(’exist’)のように、引数にはアサーション方法を渡します。上の例では要素が「存在すること」を確認しています。

引数として渡すアサーション方法は色々あり、他にも「include（含む）」「eq（イコール）」などの確認ができます。

      cy.url().should('include', 'login')
      cy.url().should('eq', 'http://127.0.0.1:8000/login');

baseUrlを設定

visit()の引数であるURLですが、対象のURLを毎回記述するのは不便です。以下のようにcypress.config.jsにベースURLを定義しておきましょう。

以下のように、baseUrl: ‘対象のURL’をe2eの中に記述します。

cypress.config.js

import { defineConfig } from "cypress";

export default defineConfig({
  e2e: {
    baseUrl: 'http://127.0.0.1:8000', //ここを追加
    setupNodeEvents(on, config) {
      // implement node event listeners here
    },
  },
});

これで先ほどの画面遷移は以下のようにすっきり書くことができます。

      //cy.visit('http://127.0.0.1:8000/login')
      cy.visit('/login')

テストの実行

いよいよテスト実行です。ここまでで出てきたコマンドを使用して、テストコードの全体は以下のようになりました。

    it('ログイン画面表示', () => {
      cy.visit('/login')

      cy.get('input#email').should('exist')
      cy.get('input#password').should('exist')
      cy.get('button[type="submit"]').contains('ログイン').should('exist')
    })

    it('未ログイン時はログイン画面へリダイレクト', () => {
      cy.visit('/dashboard')

      cy.url().should('include', 'login')
    })

Cypressブラウザを立ち上げて、ファイル名をクリックするとテストが走ります。起動・テスト実行の詳細は前回の記事をご覧ください。

テストが成功しました！テストケース名をクリックするとアサートの内容など、テストの詳細を見ることができます。

次回は、要素の入力を伴うログイン関連のテストを作成します。

参照

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

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

Tue, 28 May 2024 23:57:55 +0900

Webアプリの動作確認時、ブラウザをポチポチ手動でテストをするのも良いですが、可能な限り自動化すればテストに割く時間や手間を大きく削減できます。

テスト自動化ツールは色々なタイプがありますが、導入がシンプル・JavaScrirptベースなCypressを試してみました。

Cypressとは

Cypressとは、Webアプリケーション向けに開発されたフロントエンドの自動テストツールです。

テスト自動化というとSeleniumが有名ですが、Seleniumはブラウザ操作全般（スクレイピングなど）に使えるのに対し、Cypressはテスト用に特化して作られています。そのためスナップショット・自動待機など便利な機能が最初から用意されており、GUIを操作してテスト実行が可能なのでエンジニアでなくともとっつきやすいのではないでしょうか。

ドキュメントには使い方が詳しく解説されているので、導入前にざっと見てみるのも面白いと思います。現時点で日本語非対応ですが翻訳機能を使えば問題ありません。

また、テスト結果を保存したりチームで共有するためのクラウド機能は有料ですが、Cypressの大部分であるテスト機能そのものは無料で使えるのも嬉しいポイント。

Cypressインストールとセットアップ

CypressのインストールにはNode.js（現時点ではNode.js 18.x、もしくは20.x以上）が必要ですので、バージョンを確認。

% node -v
v18.17.1

次にインストール先のディレクトリへ移動して、以下のコマンドを実行します。今回私はテスト対象のプロジェクトルートにインストールしましたが、異なるディレクトリへインストールしてもCypressのテスト実行には問題ありません。

% cd /your/project/path
% npm install cypress --save-dev

実行後、現時点で最新のCypress13.9.0がインストールされました。では以下のコマンドでCypressを起動します。

% npx cypress open

起動直後の画面です。ここからはターミナルではなくブラウザを操作して設定を進めます。E2Eテスト、コンポーネントテストの選択肢があるので、ここではE2Eテストを選択。後からでもこの選択は変更可能です。

次に、構成ファイルの一覧が表示されます。ここもContinueをクリック。

次に、テストに使用するブラウザを選択。ここではChromeを選択します。

いよいよ最初のテスト作成へ進みます。Create new specをクリック。

ここではテストファイルの名前を編集できます。今回はデフォルトのままとして、Create spec をクリック。

作成されたテストファイルが表示されました。ファイルにはサンプルコードが記述されています。このままテストを実行することもできますが、一旦×をクリックしてダッシュボードを見てみます。

以下がダッシュボードです。テストはまだ１つしかないので一覧には先ほど作ったファイルだけがリストされていますね。

ここまでで、インストールディレクトリには以下のディレクトリ・ファイルが作成されました。

Cypress/e2e/spec.cy.js

Cypress/fixtures/example.json

Cypress/support/commands.js

Cypress/support/e2e.js

cypress.config.js

Cypress自動テスト実行

サンプルコードではありますが、さっそくテストを実行してみましょう。テストの一覧から先ほど作成したspec.cy.jsをクリックします。

すると画面が変わり、テストコードが実行されます。テストの内容はCypressのサンプルサイト（https://example.cypress.io）へアクセスするだけなので問題なく成功し、緑のOKマークが表示されています。

テスト失敗のパターンも確認してみましょう。visit()とは引数のURLへアクセスするコマンドですので、ここを立ち上げていないローカルサーバーのアドレスに変更しました。どうなるでしょうか。

Cypress/e2e/spec.cy.js

describe('template spec', () => {
  it('passes', () => {
    cy.visit('http://127.0.0.1:8000') //ここを編集
  })
})

テストコードを編集すると自動でテストが走り、以下のようにエラーメッセージが表示されました。コードのどこで失敗したのかも示してくれるのでわかりやすいですね。

少し長くなってしまったので、次回から具体的なブラウザテストを実装してゆきます。

参照

CypressでE2Eテストを自動化（２）画面表示のテスト CypressでE2Eテストを自動化（３）ログイン・ログアウト

ユーザー認証のテスト（５）Laravel 10　スロットル

Mon, 15 Apr 2024 23:01:09 +0900

Laravelユーザー認証のテスト、５回目となる今回はスロットル機能についてです。ログイン画面でEメール・パスワードを入力し一定回数以上ログインに失敗するとロックがかかる便利機能ですが、ユニットテストはどのように書くのでしょうか。

この記事では、Laravel10xにBreezeをインストールした環境でテストを作成しています。テスト環境構築を含む以前の記事は、以下のリンクからご覧いただけます。

テスト対象

デフォルトではパスワードを５回連続で間違えると６０秒ロックがかかり、ロック中はこの画像のような状態となり正しいパスワードを入力してもログインができません。

実際には、このロック機能はEメール+IPをキーとして働いており、同じIPからでもメールアドレスを変えればログイン試行が可能です。こういったことを踏まえると様々なテストケースが考えられますが、今回はシンプルに以下の項目をテストします。

・正しいEメールとパスワードでログインできる・Eメールと誤ったパスワードを入力、５回失敗までは通常のエラーメッセージが返る・６０秒経過するまでは正しいパスワードを入力してもログイン不可・６０秒経過後はログインできる

ログインスロットルのテスト

まずは正しいEメールとパスワードで問題なくログインできることのテストです。このテストはBreezeが提供してくれているテストコードに含まれており、以前にログイン機能のテストでもご紹介しています。

tests/Feature/Auth/AuthenticationTest.php

    public function test_users_can_authenticate_using_the_login_screen(): void
    {
        $user = User::factory()->create();

        $response = $this->post('/login', [
            'email' => $user->email,
            'password' => 'password',
        ]);

        $this->assertAuthenticated();
        $response->assertRedirect(RouteServiceProvider::HOME);
    }

ここは特に問題ないと思いますのでスロットル機能のテストに進みます。スロットルに関してはBreezeのテストコードが無かったので新規に作成しました。少し長いですが、以下が一連のテストコードになります。

tests/Feature/Auth/AuthenticationTest.php

    public function test_login_throttle(): void
    {
        $user = User::factory()->create(
            ['password' => 'password']
        );

        //5回の失敗までは通常のエラーメッセージが返る
        for ($i = 0; $i < 5; ++$i) {

            $response = $this->post('/login', [
                'email' => $user->email,
                'password' => 'wrong-password', //異なるパスワード
            ]);

            $response->assertSessionHasErrors(['email' => 'ログイン情報が存在しません。']);
        };

        //5回失敗後、正しいパスワードでログイン試行
        $response = $this->post('/login', [
            'email' => $user->email,
            'password' => 'password',
        ]);

        $response->assertSessionHasErrors([
            'email' => 'ログイン試行の規定数に達しました。59秒後に再度お試しください。'
        ]);

        //5０秒経過
        sleep(50);

        //まだ60秒経過していないので正しいパスワードでもログイン不可
        $response = $this->post('/login', [
            'email' => $user->email,
            'password' => 'password',
        ]);

        //メッセージの部分比較
        $response->assertInvalid([
            'email' => 'ログイン試行の規定数に達しました。'
        ]);

        sleep(10);

        //60秒経過後はログインできる
        $response = $this->post('/login', [
            'email' => $user->email,
            'password' => 'password',
        ]);

        $this->assertAuthenticated();
        $response->assertRedirect(RouteServiceProvider::HOME);
    }

まずは、正しいEメールと間違ったパスワードで５回ログインを試行しています。当然ログインは失敗しますが、その際のメッセージは通常のログイン失敗のエラーメッセージであることを確認しています。

次に、６回目に正しいEメールとパスワードでログインします。ですがロックがかかっているためログインはできません。その際のエラーメッセージは「ログイン試行の規定数に達しました。・・・」であることを確認しています。

つづいて５０秒後にも、正しいEメールとパスワードで再度ログインを試行して、ログイン不可の確認をします。

上のコードでは「５０秒後」の時間設定にはsleep(50)を使用していますが、sleep()を使うと実際にその秒数待ち時間が入るため、待ち時間が長い場合は以下のようにCarbonを使うことで実際に待つことなくテストが実行できます。

...
use Carbon\Carbon;
...
        // 50秒経過
        Carbon::setTestNow(Carbon::now()->addSeconds(50));
        // sleep(50);
...

また、「ログイン試行の規定数に達しました。**秒後に再度・・・」のエラーメッセージのアサートですが、秒数部分はどうしてもテストごとに差異が出てしまいます。エラーメッセージのアサートとして馴染みのあるassertSessionHasErrors()は全文比較するコマンドのため、メッセージの一部のみを確認したい場合はLaravel8から追加されたassertInvalid()が便利です。

使い方はassertSessionHasErrors()と同じですが、以下のようにメッセージの部分比較が可能です。

       $response->assertSessionHasErrors([
            'email' => 'ログイン試行の規定数に達しました。59秒後に再度お試しください。'
        ]);

        $response->assertInvalid([
            'email' => 'ログイン試行の規定数に達しました。'
        ]);

最後に、さらに１０秒待って、今度は６０秒経過したのでログイン可能なことを確認です。ここでも、sleep()の代わりに先ほどのCarbonのメソッドを使用して効率的にテストを進めることが可能です。

では、テストを実行してみます。

  $ php artisan test --filter=AuthenticationTest

   PASS  Tests\Feature\Auth\AuthenticationTest
  ✓ users can authenticate using the login screen                                                                                                        0.28s  
  ✓ login throttle                                                                                                                                      61.16s  

  Tests:    2 passed (20 assertions)

問題なくテストが成功しました。画面でのテストでは少し手間がかかる機能もこうやってユニットテストで確認できるのは便利ですね。

ユーザー認証のテスト（４）Laravel 10　パスワードリセット

Tue, 19 Mar 2024 12:01:40 +0900

Laravelユーザー認証のテスト4回目、今回はパスワードリセットについてです。ユーザーがパスワードを忘れた時、「パスワードを忘れた？」などのリンクからパスワードリセットリクエストを送信する、よく実装されている機能です。

テスト対象画面とテスト項目

パスワードリセットの機能をテストするにあたり、テスト対象はパスワードリセットのリクエスト画面・パスワードリセット画面の２つがあります。それぞれの画面のテスト項目にはさまざまなケースが考えられますが、今回は以下としました。

パスワードリセットのリクエスト画面

パスワードリセットリクエスト画面にアクセスできる
メールアドレスを入力し、登録済みのメールアドレスならユーザー宛てにリセットメールが送信される
未登録のメールアドレスであればメールは送信されない

パスワードリセット画面

メールに記載されたリセット用のリンクからパスワードリセット画面へアクセスできる
パスワードを新しいものに変更、その後新しいパスワードでログインができる

パスワードリセットリクエスト画面のテスト

ではまずは、「パスワードリセットリクエスト画面にアクセスできる」のテストからです。

tests/Feature/Auth/PasswordResetTest.php

    public function test_reset_password_link_screen_can_be_rendered(): void
    {
        $response = $this->get('/forgot-password');

        $response->assertStatus(200);
    }

ここは特に変わった記述はありません。未ログイン状態でアクセスすることが前提なので、テストコードは２行で完成です。

次は「メールアドレスを入力し、登録済みのメールアドレスならユーザー宛てにリセットメールが送信される」のテストですが、その前にポスト送信時に実行されるコードを確認してみると、以下のようになっていました。

app/Http/Controllers/Auth/PasswordResetLinkController.php

namespace App\Http\Controllers\Auth;

use App\Http\Controllers\Controller;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Password;
use Illuminate\View\View;

class PasswordResetLinkController extends Controller
{
...
    public function store(Request $request): RedirectResponse
    {
        $request->validate([
            'email' => ['required', 'email'],
        ]);

        // We will send the password reset link to this user. Once we have attempted
        // to send the link, we will examine the response then see the message we
        // need to show to the user. Finally, we'll send out a proper response.
        $status = Password::sendResetLink(
            $request->only('email')
        );

        return $status == Password::RESET_LINK_SENT
                    ? back()->with('status', __($status))
                    : back()->withInput($request->only('email'))
                            ->withErrors(['email' => __($status)]);
    }
}

こちらを踏まえて、Breezeが提供してくれているテストにリダイレクト先・セッションメッセージのアサートを追加しました。以下がそのテストコードになります。

tests/Feature/Auth/PasswordResetTest.php

    public function test_reset_password_link_can_be_requested(): void
    {
        Notification::fake(); //メールが実際に送信されないように

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

        $response = $this->from('forgot-password')
            ->post('/forgot-password', ['email' => $user->email]);

        $response->assertRedirect('forgot-password')
            ->assertSessionHas('status', 'パスワードリセットメールを送信しました。');

        Notification::assertSentTo($user, ResetPassword::class);
    }

ステータスメッセージとともに前画面にリダイレクトされ、ユーザー宛てにメールが正常に送信されることを確認しています。

$this->from(‘forgot-password’)ですが、これは何をしているかというとリファラーをセットしています。テストでは、ブラウザ操作時のように「前のURL」という概念が存在しません。そのためfrom()関数を使ってポスト送信時のリファラをセットしてあげる必要があります。

３つ目は、「未登録のメールアドレスであればメールは送信されない」のテストです。このケースはBreezeのテストコードには含まれていなかったため新規に作成しています。

tests/Feature/Auth/PasswordResetTest.php

    public function test_reset_password_link_request_fails_for_unregistered_email(): void
    {
        Notification::fake();

        $response = $this->from('forgot-password')
            ->post('/forgot-password', ['email' => 'unregistered@example.com']);

        $response->assertRedirect('forgot-password')
            ->assertSessionHasErrors('email', ['このメールアドレスに一致するユーザーは存在しません。']);

        Notification::assertNothingSent();
    }

from()を使ってリファラをセット・ポスト送信をするところまでは先ほどと同じです。もちろんメールアドレスは未登録のものを使用してくださいね。ポスト送信の結果からassertSessionHasErrors()を使用して、エラーメッセージemailが期待通りであることをアサートしています。

最後のassertNothingSent()は、通知が何も送信されていないことをアサートしています。

ではここまでで作成したテストを実行してみましょう。

$ php artisan test --filter=PasswordResetTest

   PASS  Tests\Feature\Auth\PasswordResetTest
  ✓ reset password link screen can be rendered                                                                    0.57s  
  ✓ reset password link can be requested                                                                          0.16s  
  ✓ reset password link request fails for unregistered email                                                      0.17s  

  Tests:    3 passed (10 assertions)
  Duration: 1.14s

問題なさそうです。

パスワードリセット画面でのテスト

次は、パスワードリセット実行画面のテストです。まずは「メールに記載されたリセット用のリンクからパスワードリセット画面へアクセスできる」をテストします。

tests/Feature/Auth/PasswordResetTest.php

    public function test_reset_password_screen_can_be_rendered(): void
    {
        Notification::fake();

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

        $this->post('/forgot-password', ['email' => $user->email]);

        Notification::assertSentTo($user, ResetPassword::class, function ($notification) {
            $response = $this->get('/reset-password/' . $notification->token);

            $response->assertStatus(200);

            return true;
        });
    }

上記はBreezeのテストコードから特に変更はしていません。コードの前半部分はユーザーの作成とポスト送信に関する記述なので先ほどまでのテストと同じで、後半のNotification::assertSentToの部分がこのテストのメインとなります。

クロージャーの引数として、$notificationを受け取っています。これはユーザーへ送信される通知メールであるResetPasswordクラスのインスタンスなので、これを使って「メールが送信されていること」だけでなく「通知メールに含まれるトークンを使ってパスワードリセット画面（/reset-password/{token}）にアクセスし、そのページが正常にレンダリングされる」ことの一連のテストが可能になります。

では次が最後のテスト項目です。「パスワードを新しいものに変更、その後新しいパスワードでログインができる」をテストします。Breezeのテストコードをベースに、成功時のセッションメッセージと新しいパスワードでログインできることのアサートを追加しました。

tests/Feature/Auth/PasswordResetTest

    public function test_password_can_be_reset_with_valid_token(): void
    {
        Notification::fake();

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

        $this->post('/forgot-password', ['email' => $user->email]);

        Notification::assertSentTo($user, ResetPassword::class, function ($notification) use ($user) {
            $response = $this->post('/reset-password', [
                'token' => $notification->token,
                'email' => $user->email,
                'password' => 'new_password', //新しいパスワード
                'password_confirmation' => 'new_password',
            ]);

            $response->assertRedirect('login')
                ->assertSessionHas('status', 'パスワードをリセットしました。');

            return true;
        });

        $this->assertGuest(); //この時点ではまだ未ログイン状態であることを確認

        $this->post('/login', [
            'email' => $user->email,
            'password' => 'new_password', //新しいパスワードでログイン
        ]);

        $this->assertAuthenticated(); //ログインできたことを確認
    }

このテストでもNotification::assertSentToが使用されていますが、今度はクロージャーの中でパスワードリセットのポスト送信を実行し、リダイレクト先・ステータスメッセージが期待通りであることを確認しています。

また、パスワードリセット完了直後はユーザーはまだ未ログイン状態となっています。そのため新しいパスワード（new_password）を使ってログインを実行し、ログインが成功することを確認しています。

ではここで作成した２つのテストを実行してみます。

$ php artisan test --filter=PasswordResetTest

   PASS  Tests\Feature\Auth\PasswordResetTest
  ✓ reset password screen can be rendered                                                                         0.60s  
  ✓ password can be reset with valid token                                                                        0.10s  

  Tests:    2 passed (8 assertions)
  Duration: 0.89s

うまくいきました！次回は、ログインスロットルに関するテストをご紹介します。

ユーザー認証のテスト（３）Laravel 10　ログアウト

Sat, 17 Feb 2024 10:13:04 +0900

前回のログイン・ログイン失敗のテストに続き、今回はログアウトのテストをご紹介します。また認証機能にBreezeを使用した環境で、ログアウト時のリダイレクト先の変更も行います。

ログアウトのテスト

前回と同じくBreezeが提供してくれているテストをベースに、テスト名はそのままでアサーションとポスト送信の記述を少し変更しています。

tests/Feature/Auth/AuthenticationTest.php

    public function test_users_can_logout(): void
    {
        $user = User::factory()->create();

        $this->actingAs($user); //$userを認証済み状態に

        $this->assertAuthenticated(); //ログインしていることを確認

        $response = $this->post('/logout');

        $this->assertGuest();         //ログアウトしていることを確認

        $response->assertRedirect('/');
    }

POST送信でログアウトを実行し、正しく認証が削除されているか、リダイレクトされているかをチェックしています。またactingAs()を使うことで、ログイン処理を記述せずに対象のユーザーを認証済み状態に設定できます。

このテストでは分かりやすいようにログアウト動作の前後で認証状態をチェックしていますが、ログアウト前のチェックが不要な場合は以下のように、actingAs()とpost()を１行で書くこともできます。

        $response = $this->actingAs($user)->post('/logout');

では、テストを実行してみます。

$ php artisan test --filter=test_users_can_logout

   PASS  Tests\Feature\Auth\AuthenticationTest
  ✓ users can logout                                                                                                                   0.63s  

  Tests:    1 passed (4 assertions)
  Duration: 0.93s

問題なさそうですね。

ログアウト後の遷移先を変更（Breeze使用）

デフォルトでログアウト後のリダイレクト先はルート画面となっていますが、異なる画面へ遷移するよう変更したいケースも多いと思います。

Breezeでログアウトの処理がどのように定義されているのか見てみます。まずはルーティングから。

routes/auth.php

...
    Route::post('logout', [AuthenticatedSessionController::class, 'destroy'])
                ->name('logout');
...

AuthenticatedSessionControllerのdestroy()に定義されていることが分かりました。同ファイルを一部抜粋したものが以下になります。

app/Http/Controllers/Auth/AuthenticatedSessionController.php

namespace App\Http\Controllers\Auth;

use App\Http\Controllers\Controller;
use App\Http\Requests\Auth\LoginRequest;
use App\Providers\RouteServiceProvider;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Route;
use Inertia\Inertia;
use Inertia\Response;

class AuthenticatedSessionController extends Controller
{
...
    /**
     * Destroy an authenticated session.
     */
    public function destroy(Request $request): RedirectResponse
    {
        Auth::guard('web')->logout();

        $request->session()->invalidate();

        $request->session()->regenerateToken();

        return redirect('/');
    }
}

ログアウトの処理と、最後にリダイレクト先が指定されていますね。redirect()の部分を、ログイン画面にリダイレクトするよう修正しました。

        return redirect('/login');

ここで、ログアウトのテストコードに戻ります。

まだテストコードへはリダイレクト先の変更が反映されていないので、テスト失敗が正しい挙動です。念の為テストを実行して確認してみましょう。

$ php artisan test --filter=test_users_can_logout

   FAIL  Tests\Feature\Auth\AuthenticationTest
  ⨯ users can logout                                                                                                                   0.51s  
  ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────  
   FAILED  Tests\Feature\Auth\AuthenticationTest > users can logout                                                                           
  Failed asserting that two strings are equal.
  -'http://localhost'
  +'http://localhost/login'

ちゃんとリダイレクト先相違のエラーが出ました。コントローラーの変更が反映されていることが分かったので、現在の仕様に合わせてテストを書き換えます。

    public function test_users_can_logout(): void
    {
        $user = User::factory()->create();

        $response = $this->actingAs($user)->post('/logout');

        $this->assertGuest();

        $response->assertRedirect('/login'); //リダイレクト先を修正
    }

テストを実行します。

$ php artisan test --filter=test_users_can_logout

   PASS  Tests\Feature\Auth\AuthenticationTest
  ✓ users can logout                                                                                                                   0.49s  

  Tests:    1 passed (3 assertions)
  Duration: 0.72s

成功しました！次回は、パスワードのリセットに関するテストをご紹介します。

ユーザー認証のテスト（２）Laravel 10　ログイン

Sat, 20 Jan 2024 12:39:28 +0900

前回の画面表示テストに続き、今回もLaravelユーザー認証のテストです。正しいＥメールとパスワードでログインが成功するケースと、間違ったパスワードでログインしログインに失敗する２つのケースについて、テストを作成します。

エラーメッセージの日本語化

前回、Laravelと認証機能のBreezeをインストールした直後の環境でテストを作成しました。後でご紹介するログイン失敗のケースではエラーメッセージも含めてアサートしたいので、まずは日本語化の設定から進めてゆきます。

Githubで公開されているBreezejpという日本語化パッケージを使わせていただきます。名前にBreezeとついていますがJetstream、Laravel UIなどの環境でも使用可能とのこと。適用方法もとても簡単で、以下の２つのコマンドを実行するだけです。

まず、composerでパッケージをインストールします。

$ composer require askdkc/breezejp --dev

次に以下のコマンドを実行。

$ php artisan breezejp
Laravel Breeze用に日本語翻訳ファイルを準備します
config/app.phpのlocaleをjaにします

 GitHubリポジトリにスターの御協力をお願いします🙏 (yes/no) [yes]:
 > yes

Thank you! / ありがとう💓
日本語ファイルのインストールが完了しました!

これでプロジェクト直下にlangディレクトリと、日本語用ファイルが作成できました。また出力内容からも分かるように、言語ファイルの設置だけでなくconfig/app.phpのlocaleもjaに変更してくれています。

これで日本語化の設定は完了です。

ここまででBreezeと、Breezejpの２つが出てきました。名前が似ていて少しややこしいのですが、前者は認証機能を簡単に実装できるパッケージで（前回の記事でインストールしました）、後者は今回インストールした日本語化のパッケージになります。

テスト用Userデータ

次に、テストに必要なダミーユーザーを作成するためのFactoryについてです。Laravelデフォルトですでに用意されているので、内容を確認してみます。

database/factories/UserFactory.php

...
class UserFactory extends Factory
{
    protected static ?string $password;

    /**
     * Define the model's default state.
     *
     * @return array<string, mixed>
     */
    public function definition(): array
    {
        return [
            'name' => fake()->name(),
            'email' => fake()->unique()->safeEmail(),
            'email_verified_at' => now(),
            'password' => static::$password ??= Hash::make('password'),
            'remember_token' => Str::random(10),
        ];
    }
...

パスワードには、”password”という文字をハッシュ化した値が保存されるようになっているようですね。

ログイン成功のテスト

準備ができたので、テストをしてゆきましょう。まずはログイン成功のテストです。前回と同じくBreezeが用意してくれているユニットテストを使用しますが、アサートを少し追加しています。

tests/Feature/Auth/AuthenticationTest.php

    public function test_users_can_authenticate_using_the_login_screen(): void
    {
        $user = User::factory()->create();

        $this->assertGuest(); //未ログイン状態であることをチェック

        $response = $this->post('/login', [
            'email' => $user->email,
            'password' => 'password',
        ]);

        $this->assertAuthenticated(); //ログインが成功したことをチェック

        $response->assertRedirect(RouteServiceProvider::HOME);
    }

このテストでは、Laravelが用意してくれているログイン認証のための便利なアサーションを２つ使用しています。assertGuest()は、ユーザーが未ログインであること、またassertAuthenticated()は、ユーザーが認証済みであることをアサートしています。ログイン前後の認証状態を効率的にチェックできてとても便利ですね。

この２つの関数は通常、guardを引数として受け取ります。上記のテストでは引数を省略していますが、その場合にはconfig/auth.phpのdefaultsセクションで定義されているwebガードがデフォルトとして使用されます。

では以下のように、guardsの定義にwebだけでなくadminも定義されている場合はどうでしょうか。

config/auth.php

・・・
    'defaults' => [
        'guard' 　　　　　　　　=> 'web',
        'passwords' => 'users',
    ],
・・・
    'guards' => [
        'web' => [
            'driver'   => 'session',
            'provider' => 'users',
        ],
        'admin' => [
            'driver'   => 'session',
            'provider' => 'admin',
        ],
    ],
・・・

adminガードに対して認証確認を行いたい場合は、以下のように引数にadminを渡します。環境に併せて適宜ご変更ください。

　　       $this->assertGuest('admin'); 
        $this->assertAuthenticated('admin');

ログイン失敗のテスト

次はログインに失敗する場合のテストです。正しいパスワードは先ほどのFactoryで設定されている通り"password"ですが、失敗するために"wrong-password“でログインしてみます。

tests/Feature/Auth/AuthenticationTest.php

    public function test_users_can_not_authenticate_with_invalid_password(): void
    {
        $user = User::factory()->create();

        $this->assertGuest(); //未ログイン状態であることをチェック

        $response = $this->post('/login', [
            'email' => $user->email,
            'password' => 'wrong-password',
        ]);

        $response->assertSessionHasErrors([
            'email' => 'ログイン情報が存在しません。'
        ]);

        $this->assertGuest();
    }

エラーメッセージは先ほど日本語化したため、正しく設定されていれば日本語のメッセージが返るはずです。

では、ログイン成功・失敗のテストを実行してみましょう。

$ php artisan test --filter=AuthenticationTest

   PASS  Tests\Feature\Auth\AuthenticationTest
  ✓ users can authenticate using the login screen                                              0.58s  
  ✓ users can not authenticate with invalid password                                           0.27s  

  Tests:    2 passed (8 assertions)
  Duration: 1.04s

テストが成功しました！

次回は、ログアウト関連のテストをご紹介します。

ユーザー認証のテスト（１）Laravel 10

Thu, 21 Dec 2023 08:43:51 +0900

当サイトでご紹介しているユーザー認証のテストはLaravel5.4のもので、Laravel10となった今ではアサート関数やfactory関連の記述も変化しているため新しいものに書き換えることにしました。Laravelの新規インストールから、認証周りのテスト作成をご紹介します。また、認証機能にはBreezeを使用しました。

Breezeとは?

Breezeについては、Laravelのドキュメントにて以下のように紹介されています。

Laravel Breezeは、ログイン、ユーザー登録、パスワードリセット、メール確認、パスワード確認など、すべての認証機能を最小かつシンプルにLaravelへ実装したものです。

Laravel uiの後継という立ち位置で、Laravel7から採用されています。フロントの実装もついてくるのでインストールするだけですぐに認証機能を利用することができます。

プロジェクト新規作成・Breezeインストール

まずはLaravelをインストールします。本記事作成時のバージョンは10.2.9でした。インストール先のディレクトリ名は適宜書き換えてくださいね。

$ composer create-project laravel/laravel test-project

$ cd test-project

次に、.envを編集します。今回DBはsqliteを使用しますので、DB_CONNECTIONを編集し、以降はコメントアウトします。

.env

DB_CONNECTION=sqlite
# DB_HOST=127.0.0.1
# DB_PORT=3306
# DB_DATABASE=laravel
# DB_USERNAME=root
# DB_PASSWORD=

次はマイグレーションを実行します。sqliteのデフォルトでは、/database/database.sqlite というファイルが作成されます。

$ php artisan migrate

ここまで進めたら、いよいよBreezeをインストールします。オプションについていくつか質問されますが、テスト用フレームワークはPHPUnitを選択してください。

$ composer require laravel/breeze --dev

$ php artisan breeze:install

┌ Which Breeze stack would you like to install? ───────────────┐
│ Blade with Alpine                                            │
└──────────────────────────────────────────────────────────────┘

┌ Would you like dark mode support? ───────────────────────────┐
│ No                                                           │
└──────────────────────────────────────────────────────────────┘

┌ Which testing framework do you prefer? ──────────────────────┐
│ PHPUnit                                                      │
└──────────────────────────────────────────────────────────────┘

これでインストール関連は完了です。テストを書くだけなら不要ですが、せっかくなのでブラウザの表示も確認してみましょう。

$ php artisan serve

http://127.0.0.1:8000/register へアクセスすると、以下のようなユーザー登録画面が表示されます。

テストの準備

phpunit.xmlを編集します。今回はテストでもsqliteを使用するので、以下のようにDB_CONNECTION、DB_DATABASEのコメントアウトを外すだけです。

phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true"
>
    <testsuites>
        <testsuite name="Unit">
            <directory>tests/Unit</directory>
        </testsuite>
        <testsuite name="Feature">
            <directory>tests/Feature</directory>
        </testsuite>
    </testsuites>
    <source>
        <include>
            <directory>app</directory>
        </include>
    </source>
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="BCRYPT_ROUNDS" value="4"/>
        <env name="CACHE_DRIVER" value="array"/>
        <env name="DB_CONNECTION" value="sqlite"/> //ここのコメントアウトを外す
        <env name="DB_DATABASE" value=":memory:"/> //ここのコメントアウトを外す
        <env name="MAIL_MAILER" value="array"/>
        <env name="QUEUE_CONNECTION" value="sync"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="TELESCOPE_ENABLED" value="false"/>
    </php>
</phpunit>

これで準備は完了です。あとはテストを書いてゆくだけなのですが、なんとBreezeはインストール直後の状態でユーザー登録やログイン認証・パスワード変更のテストが一通り揃っています。

以下はtestsディレクトリのスクリーンショットです。

これだけでテストは十分揃っているようですが、今回は少し付け足したいケースもあったのでこれらのテストを参考にしながら認証テストを作成することにします。

画面表示のテスト

テストを書くにあたりルーティングを確認します。php artisan route:listでリストを出力すると、以下のようになっていました。

このルーティングの中から、まずはログイン画面（login）の表示と、ログイン後のダッシュボード（dashboard）の表示をテストしてみます。AuthenticationTest.phpには初期状態で４つのテストが用意さてれていますが、まずは簡単なテストから、ということでシンプルに以下のように編集しました。１つ目はデフォルトで用意されているテストで、２つ目は新しく追加したものです。

tests/Feature/Auth/AuthenticationTest.php

namespace Tests\Feature\Auth;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class AuthenticationTest extends TestCase
{
    use RefreshDatabase;

    public function test_login_screen_can_be_rendered(): void
    {
        $response = $this->get('/login');

        $response->assertStatus(200);
    }

    public function test_unauthenticated_user_cannot_view_dashboard(): void
    {
        $response = $this->get('dashboard');

        $response->assertRedirect('/login');
    }

}

１つ目のテストは、ログイン画面の表示を確認しています。問題なく表示されればステータスのコードは200となり、テストが通るはずです。

２つ目は、認証が必要な画面にアクセスしています。まだログインしていない状態なので、ログイン画面にリダイレクトされる挙動を期待しています。

テストを実行してみると、成功しました。

$ vendor/bin/phpunit --filter AuthenticationTest --testdox
PHPUnit 10.5.1 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 00:01.134, Memory: 38.50 MB

OK (2 tests, 3 assertions)

アサートは２つなのに3 assertionsとなっているのは、２つ目のテストのassertRedirectが２つのアサートを内包しているためです。１つは、リダイレクトされたこと。もう１つは、リダイレクトの先が/loginであることです。

次回は、ログイン関連のテストをご紹介いたします。

Laravel新Mailableのメール送信ユニットテスト

Tue, 17 Oct 2023 01:13:17 +0900

LaravelのMailableはメール送信に便利なクラスですが、テストでも同様にMailableをアサートするための便利なメソッドが用意されています。この記事では、Laravel10系の新しいMailableを使ったメール送信テストの書き方をご紹介します。

新Mailableでのメール送信についてはこちらの記事をご覧ください。

テスト対象

テスト対象は以下のクラスです。送信先のメールアドレスを受け取って送信するシンプルなものです。

App/Models/Message.php

class Message extends Model
{
    public static function sendMail($email)
    {
        Mail::to($email)->send(new BuildMail);
    }
}

sendの引数に渡しているBuildMailがMailableを継承しているクラスとなり、以下のように定義しています。

App/Mail/BuildMail.php

namespace App\Mail;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Mail\Mailable;
use Illuminate\Mail\Mailables\Attachment;
use Illuminate\Mail\Mailables\Content;
use Illuminate\Mail\Mailables\Envelope;
use Illuminate\Queue\SerializesModels;

class BuildMail extends Mailable
{
    use Queueable, SerializesModels;
 
    /**
     * Create a new message instance.
     */
    public function __construct()
    {
        //
    }
 
    /**
     * Get the message envelope.
     */
    public function envelope(): Envelope
    {
        return new Envelope(
            subject: 'Test Mail',
            from: 'from@example.com',
        );
    }
 
    /**
     * Get the message content definition.
     */
    public function content(): Content
    {
        return new Content(
            html: 'emails.test',
        );
    }
 
    /**
     * Get the attachments for the message.
     *
     * @return array<int, \Illuminate\Mail\Mailables\Attachment>
     */
    public function attachments(): array
    {
        return [
            Attachment::fromPath(
                storage_path('app/img/testmail.jpg')
            ),
        ];
    }
}

メールの送信回数をテスト

まず、メールが１回送信されたことをテストしてみましょう。テストコードは以下のようになります。

   public function sendMailTest()
    {
        Mail::fake();

        //テスト対象の関数を実行
        Message::sendMail('to@example.com');

        Mail::assertSent(BuildMail::class, 1);
    }

最初にMail::fake()を使用しています。テストでは実際にメールを送信する必要はないので、メール送信をモック化し実際に送信されることを防いでいます。

Mail::assertSent()では、メールが送信されたかどうか、またその回数をアサートしています。第一引数がメール送信クラス、第二引数が期待する送信回数です。今回は１回送信されることを確認するので、１としています。

これでテストを実行すると、無事OKとなりました。

% vendor/bin/phpunit --filter sendMailTest        
PHPUnit 10.4.1 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 00:00.447, Memory: 26.00 MB

OK (1 test, 1 assertions)

もし期待と異なりメールが２通送信された場合、以下のエラーが返ってきます。エラーメッセージにも送信数が違う旨が書いてあるので分かりやすいですね。

The expected [App\Mail\BuildMail] mailable was sent 2 times instead of 1 times.
   Failed asserting that 2 is identical to 1.

件名・宛先をテスト

件名や宛先など、より詳しく送信メールの情報をアサートしたい場合も同様にMail::assertSent()を使います。その際、以下のように第二引数のクロージャーでBuildMailクラスのインスタンスである$mail変数を受け取る必要があります。

        Mail::assertSent(BuildMail::class, function ($mail) {
            return $mail->hasTo('to@example.com') &&
                $mail->hasFrom('from@example.com') &&
                $mail->hasSubject('Test Mail');
        });

hasToで送信先のメールアドレスを、hasFromで送信元のメールアドレスを、またhasSubjectでメールの件名をそれぞれアサートしています。新・旧Mailableで関数名も同じですね。

テストを実行してみると、こちらもOKが出ました。

% vendor/bin/phpunit --filter sendMailTest        
PHPUnit 10.4.1 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 00:00.353, Memory: 26.00 MB

OK (1 test, 1 assertions)

このテストの際、新Mailableになって便利になったと感じたことがあります。

旧Mailableでは、buildメソッドを使用しsubjectやfromを指定しているケースも少なくないと思います。その場合、テストコード内でもbuildの記述が必要でした。以下のようにです。

         Mail::assertSent(BuildMail::class, function ($mail) {

            $mail->build();

            return $mail->hasTo('to@example.com') &&....
        });

ですが、buildを使用せず新Mailableで提供されるようになったenvelopeやcontentを使用していれば、特に何も気にしなくともアサートは成功します。これはテストを書く立場として少し嬉しいです。

添付ファイルをテスト

次に、添付ファイルが期待通りか確認します。

BuildMailの定義でも使用していたAttachmentクラスを使うので、useをお忘れなく。

...
use Illuminate\Mail\Mailables\Attachment;
...
    public function sendMailTest()
    {
        ...//関数の実行など
        Mail::assertSent(BuildMail::class, function ($mail) {
            return $mail->hasAttachment(
                Attachment::fromPath(storage_path('app/img/testmail.jpg')),
            );
        });
    }

複数のメールを確認

１回で複数件送信されるメールのアサートも簡単です。以下は、計３通のメールが送信されたか、その宛先がそれぞれ期待通りかをアサートする場合のテストコードです。

        Mail::assertSent(BuildMail::class, 3);

        Mail::assertSent(BuildMail::class, function ($mail) {
            return $mail->hasTo('member1@example.com');
        });

        Mail::assertSent(BuildMail::class, function ($mail) {
            return $mail->hasTo('member2@example.com');
        });

        Mail::assertSent(BuildMail::class, function ($mail) {
            return $mail->hasTo('member3@example.com');
        });

このように、それぞれ順番にアサートを記述するだけで大丈夫です。こちらも新・旧Mailableで特に変わりはありません。

以上のように、新しいMailableでも旧とほとんど変わらない書き方でテストができます。どれもメールテストではよく使うものだと思いますので、ぜひご活用ください。

Mockery overload を使用してユニットテスト

Sat, 26 Aug 2023 04:03:53 +0900

前回は、Mockeryを使用したテストの基本的な書き方について解説しました。今回はモックしにくいケースでどのようにテストを書くのか、overloadを使った方法をご紹介します。

前回はこちらから閲覧できます。

モック対象を new しているケース

テスト対象クラスは以下のようになっています。外部APIを介してデータを取得しリストを返却、という部分は前回と同じですが、constructの部分は少し違います。

class TestApi
{
  private $connection;

  public function __construct()
  {
    $this->connection = new TestOAuth;
  }

  public function getList(string $param)
  {
    $list = $this->connection->get($param);

    return $list->statuses;
  }
}

モック対象であるTestOAuthを、インジェクションではなくconstructの中でnewしています。これではTestOAuthのモックを作成しても、前回のように引数として渡すことができません。

overloadを付けてモックを作成

そこで使用されるのがoverloadです。

モック作成時、以下のようにoverloadプレフィックスを付けることでプロダクトコードを変更することなく対象をモックできます。

        \Mockery::mock('overload:' . TestOAuth::class);

テストコード全体は以下のようになります。モックオブジェクト作成時にoverloadを使用している以外は、ほぼ前回と同じように記述しています。

    public function getListTest()
    {
　　　　　　　　　　　　　　　　//モックを作成
        $mock = \Mockery::mock('overload:' . TestOAuth::class);

        $mock->shouldReceive('get')
            ->once()
            ->with('test')
            ->andReturn((object) [
                'statuses' =>
                [
                    (object)['mockからのレスポンス１'],
                    (object)['mockからのレスポンス２']
                ]
            ]);

        //テストここから
        $testApi = new TestApi();

        $actual = $testApi->getList('test');

        $this->assertCount(2, $actual);
    }

onceでメソッドが１度だけ呼ばれることを、withでメソッドに渡される引数が「test」であることを、期待値としてモックオブジェクトに設定しています。

またandReturnで、APIからのレスポンスが2つのオブジェクトを含む配列を持つstatusesプロパティが返るようにしました。

これでテストを実行すると、

% vendor/bin/phpunit --filter getListTest          
PHPUnit 9.5.16 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 00:00.420, Memory: 22.00 MB

問題なく通りました。

ちなみに、overloadするだけで本当にモックが使用されているのか？と心配になるかと思いますので、モックに差し代わっているかどうかチェックしてみます。

プロダクトコード内、モックからのレスポンスを受け取っている変数をダンプして中身を確認します。以下の箇所ですね。

    $list = $this->connection->get($param);

テストを動かしながら$listの中身を確認すると、以下のようになりました。

 {#727
  "statuses": array:2 [
    0 => {#328
      "0": "mockからのレスポンス１"
    }
    1 => {#333
      "0": "mockからのレスポンス２"
    }
  ]
}

ちゃんとモックオブジェクトに設定した値が返ってきています。

実際の呼び出しがモックの期待値と異なるケース

モックオブジェクトに設定した期待値と、実際の結果が異なった場合どのような挙動になるのでしょうか。エラーケースを見てみましょう。

まずは、呼び出し回数が異なる場合です。今回のテストではgetメソッドが１回呼ばれることを期待していました。

しかし実際にはgetが２回呼ばれたとします。テストを実行すると、以下のエラーとなりました。

    Mockery\Exception\InvalidCountException: Method get(<Any Arguments>) from Abraham\TestOAuth should be called
    exactly 1 times but called 2 times.

エラーメッセージにも、２度呼ばれた旨が書いてあって分かりやすいですね。

次は、引数が期待と異なった場合です。引数が「test」であることを期待していたところ、実際に使用された引数は「テスト」だったとします。

テストを実行すると・・・

   Mockery\Exception\NoMatchingExpectationException: No matching handler found for Abraham\TestOAuth::get('テスト'). Either the method was unexpected or its arguments matched no expected argument list for this method

こちらも無事エラーとなり、エラーメッセージには引数がマッチしない旨の記述があります。

overloadは対象クラスがすでにnewされている場合には使えないなど、少し制約はありますがモックが難しい場面ではとても頼りになるのでぜひ活用してみてくださいね。

Mockeryで外部APIをモックしてユニットテスト

Tue, 01 Aug 2023 06:11:58 +0900

テスト対象が外部APIにアクセスしている場合、テストの度にAPIにアクセスするためテストに時間がかかる・APIが落ちているとテストも落ちる、といった不便さがあります。そこでモックを使用すると、APIを介すことなく対象のテストを行うことができて便利です。本記事では、Mockeryを使ったモックの作成方法・テストの書き方をご紹介します。

テスト対象クラス

以下のTestApiがテスト対象です。外部APIを介してデータを取得し、リストを返却。

なんらかのエラーでデータが取得できなかった場合にはfalseを返すというシンプルなものです。

class TestApi
{
  private $connection;

  public function __construct(TestOAuth $testOAuth) // ←　TestAuthがモックの対象
  {
    $this->connection = $testOAuth;
  }

  public function getList(string $param)
  {
    $list = $this->connection->get($param);

    //データ取得できなかった場合
    if (property_exists($list, 'errors')) {

      return false;
    }

    return $list->statuses;
  }
}

また、モック対象は、TestOAuthです。TestApiのコンストラクタでインジェクションされていますね。

Mockeryでモックしてテスト：正常ケース

テストコード全体は以下のようになります。

    public function getListTest()
    {
　　　　//モックを作成
        $mock = \Mockery::mock(TestOAuth::class);

        $mock->shouldReceive('get')
            ->once()
            ->with('正常test')
            ->andReturn((object) [
                'statuses' =>
                [
                    (object)['data1'],
                    (object)['data2']
                ]
            ]);

        //テストここから
        $testApi = new TestApi($mock);

        $actual = $testApi->getList('正常test');

        $this->assertCount(2, $actual);
    }

モック部分を解説します。

        $mock = \Mockery::mock(TestOAuth::class);

まず最初に、mockメソッドでモックインスタンスを作成します。引数にはモック対象のTestOAuthを渡します。

        $mock->shouldReceive('get')
            ->once()
            ->with('正常test')
            ->andReturn([
                'statuses' =>
                [
                    (object)['data1'],
                    (object)['data2']
                ]
            ]);

次に、作成したモックインスタンスに対してgetメソッドが呼ばれた際の振る舞いを指定しています。

onceは、メソッドが１度だけ呼ばれること。

withは、getメソッドに渡される引数が「正常test」であること。

そして、最後のandReturnではAPIからのレスポンスにあたる部分で、このモックでは2つのオブジェクトを含む配列を持つstatusesプロパティが返るようにしています。

また、モックインスタンスは作成しただけではテストに反映されません。以下のようにコンストラクタに渡すことでTestApiのnew時にDIされ、実際のTestOAuthではなくモックが使用されるようになります。

       $testApi = new TestApi($mock);

テストは以下のように、コマンドラインで実行します。

 $ vendor/bin/phpunit --filter getListTest
PHPUnit 9.5.16 by Sebastian Bergmann and contributors.

.                                                                1 / 1 (100%)

Time: 00:00.131, Memory: 22.00 MB

無事テストが通ったので、モックに設定したふるまい（getが１度呼ばれる・引数の中身）が正常であったことが確認できました。

Mockeryでモックしてテスト：エラーケース

次は、エラーケースのテストになります。テスト対象メソッドの以下にあたる箇所ですね。

    //データ取得できなかった場合
    if (property_exists($list, 'errors')) {

      return false;
    }

APIからのレスポンスにerrorsというプロパティが含まれている場合に、正しくfalseが返るかをテストします。

そのため、モック作成部分では以下のように指定します。

        $mock = \Mockery::mock(TestOAuth::class);

        $mock->shouldReceive('get')
            ->once()
            ->with('エラーtest')
            ->andReturn(['errors' => []]);

モックオブジェクトの作成やgetが１度呼ばれるという箇所は同じですが、andReturnで返り値にerrorsプロパティを含むように記述しています。

モック部分を含めたテストの全文は以下のようになります。

    public function getListTest_error()
    {
        $mock = \Mockery::mock(TestOAuth::class);

        $mock->shouldReceive('get')
            ->once()
            ->with('エラーtest')
            ->andReturn(['errors' => []]);

        $testApi = new TestApi($mock);

        $actual = $testApi->getList('エラーtest');

        $this->assertEquals(false, $actual);
    }

これでテストを実行しOKであれば、呼ばれたモックオブジェクトの振る舞いが期待通りかに加え、正しくfalseが返っていることが確認できます。

Laravel factoryでテスト用データを作成（３）sequence

Mon, 10 Jul 2023 01:51:16 +0900

factoryを使ったダミーデータ作成方法の3回目です。今回は、複数のデータ作成に便利なsequenceメソッドと、そのユースケースをご紹介します。

以前の投稿はこちらから閲覧できます。（１）・（２）

前回、同じく複数データを作成するcreateManyメソッドを使った記述をご紹介しました。

少し振り返りになりますが、name属性がそれぞれ「高橋・佐藤・田中」のデータをcreateManyで作成する場合、以下のように記述します。

        User::factory()->createMany([
            ['name' => '高橋'],
            ['name' => '佐藤'],
            ['name' => '田中'],
        ]);

作成したいデータを配列でcreateManyに渡すことで、簡潔に記述することができます。

では、sequenceで同じデータを作る場合はどのようにするのでしょうか。

sequenceで複数データを作成

先ほどと同じ、name属性が「高橋・佐藤・田中」のデータを作成してみましょう。以下のように記述します。

        User::factory()
            ->count(3)
            ->sequence(
                ['name' => '高橋'],
                ['name' => '佐藤'],
                ['name' => '田中']
            )
            ->create();

countメソッドに作成件数を指定し、sequenceには作成したいデータを渡します。またcreateメソッドも繋ぐ必要があります。

このケースではcreateManyと比較して、sequenceの方がやや冗長に見えますよね。ですが、以下のようなケースならどうでしょう。

sequenceが適しているケース（１）

sex属性が「女性」と「解答なし」のデータをそれぞれ3件、全6件分作成したい。このようなケースでは、sequenceを使って以下のように記述できます。

        User::factory()
            ->count(6)
            ->sequence(
                ['sex' => '女性'],
                ['sex' => '解答なし'],
            )
            ->create();

tinkerで実行すると、「女性・解答なし・女性・解答なし….」と繰り返すデータがちゃんと６件作成されていることがわかります。

= Illuminate\Database\Eloquent\Collection {#29800
    all: [
      App\Models\User {#29813
        sex: "女性",
        name: "三宅 涼平",
        id: 142,
      },
      App\Models\User {#29793
        sex: "解答なし",
        name: "渡辺 充",
        id: 143,
      },
      App\Models\User {#29777
        sex: "女性",
        name: "近藤 裕樹",
        id: 144,
      },
      App\Models\User {#29845
        sex: "解答なし",
        name: "伊藤 加奈",
        id: 145,
      },
      App\Models\User {#29771
        sex: "女性",
        name: "三宅 加奈",
        id: 146,
      },
      App\Models\User {#29781
        sex: "解答なし",
        name: "青田 くみ子",
        id: 147,
      },

sequenceを使わなくても、以下のように「女性」のレコード・「解答なし」のレコードをそれぞれで作成しても良いかもしれません。

       User::factory(3)->create(['sex' => '女性']);
       User::factory(3)->create(['sex' => '解答なし']);

ただ、その場合作成されたレコード群は「女性・女性・女性・解答なし・解答なし・解答なし」と不自然にデータが固まってしまうので、テストケースによってどちらにするかは使い分けるとよさそうです。

ちなみに、今のようなデータをcreateManyを使って作成しようとすると、

       User::factory()->createMany([
            ['sex' => '女性'],
            ['sex' => '解答なし'],
            ['sex' => '女性'],
            ['sex' => '解答なし'],
            ['sex' => '女性'],
            ['sex' => '解答なし'],
        ]);

このように6件分のデータを１つ１つ配列に渡さないといけないので、より冗長になってしまいます。

sequenceが適しているケース（２）

もう１つのsequenceが適しているケースは、「データに一意性を持たせたい場合」です。

以下は、私が関わらせていただいているプロジェクトで使われているコードを本記事用に少し変更したものですが、sequenceの使用例としてまさにぴったりです。

テスト用に47都道府県のレコードを作成したい。県名は、連続した一意性のあるデータとしたい。そういう場合、以下のようなシンプルな記述で作成できます。

        Prefecture::factory()->count(47)
            ->sequence(function ($sequence) {
                return ['name' => "都道府県{$sequence->index}"];
            })->create();

上記のコードではクロージャーで引数として$sequenceを受け取っています。$sequenceオブジェクトが持つindexプロパティを使用し、県名に連番を割り当てています。

以下はtinkerの実行結果です。「都道府県0、都道府県1、都道府県2、都道府県3、都道府県4、、、」と連続した番号が割り当てられることで、それぞれのデータに一意性を持たせることができます。

= Illuminate\Database\Eloquent\Collection {#29831
    all: [
      App\Models\Prefecture {#29822
        id: 20,
        name: "都道府県0",
      },
      App\Models\Prefecture {#29825
        id: 21,
        name: "都道府県1",
      },
      App\Models\Prefecture {#29821
        id: 22,
        name: "都道府県2",
      },
      App\Models\Prefecture {#29820
        id: 23,
        name: "都道府県3",
      },
      App\Models\Prefecture {#29819
        id: 24,
        name: "都道府県4",
      },
      App\Models\Prefecture {#29818
        id: 25,
        name: "都道府県5",
      },
      App\Models\Prefecture {#29817
        id: 26,
        name: "都道府県6",
      },
      App\Models\Prefecture {#29816
        id: 27,
        name: "都道府県7",
      },
      .
      .
      .

$sequenceのindexプロパティは「0」始まりなので、連番の始まりを「１」にしたい場合は、コールバック関数の中で +1 としてください。

            ->sequence(function ($sequence) {
                return ['name' => "都道府県" . ($sequence->index + 1)];
            })

sequenceはそれほど出番が多いメソッドではないかもしれませんが、適した箇所に使うととっても便利です。ぜひご活用ください。

Laravel factoryでテスト用データを作成（２）

Wed, 21 Jun 2023 02:26:30 +0900

factoryを使ったダミーデータ作成方法の２回目です。前回は単一モデルを扱った内容でしたが、今回は「１対多」のリレーションデータを作成します。

前回はこちらから閲覧できます。

１対多のリレーション

店舗（Shop）と、店舗に複数の商品（Product）が属している１対多のリレーションです。商品テーブルは、店舗のプライマリキーであるshop_idを外部キーとして格納しています。

factoryの定義

factoryでダミーデータを作るにあたり、factoryにモデルの属性値を定義する必要があります。

まず、Shopに対して以下のように定義します。

ShopFactory.php

class ShopFactory extends Factory
{
    public function definition()
    {
        return [
            'name' => $this->faker->name(),
        ];
    }
}

Product側も同様です。子は関連する親のid情報を持つ必要があるので、shop_idカラムも定義します。

ProductFactory.php

class ProductFactory extends Factory
{
    public function definition()
    {
        return [
            'name'    => $this->faker->name(),
            'shop_id' => $this->faker->randomNumber(),
        ];
    }
}

作成したfactoryの対象Modelへの紐付けも忘れずに行いましょう。HasFactoryトレイトを追加します。

Shop.php

use Illuminate\Database\Eloquent\Factories\HasFactory;

class Shop extends Model
{
    use HasFactory; //★
    ....
}

Product.php

use Illuminate\Database\Eloquent\Factories\HasFactory;

class Product extends Model
{
    use HasFactory; //★
    ....
}

ここまででで、factoryを使用する準備ができました。

factoryでリレーションデータを作成

では早速テスト用のダミーデータを作ってみましょう。前回の単一Modelデータの作成と同じ書き方で、簡単にリレーションデータが作成できます。

        $shop = Shop::factory()->create();

        Product::factory()->create([
            'shop_id' => $shop->shop_id
        ]);

まず親を作成し、子のデータを作成する際shop_idへ親のデータを渡すことでそれぞれのインスタンスを紐づけています。

これは見た目にも分かりやすくとっつきやすい書き方ですが、以下のようにforメソッドを使用するともっとコンパクトに記述することができます。

        $product = Product::factory()
            ->for(Shop::factory()->create())
            ->create();

している事は先ほどと同じで、Productと、それに関連するShopデータの作成です。

tinkerで実行してみると、以下のような結果となりました。

= App\Models\Product {#29792
    product_id: 36958,
    shop_id: 4763,
    name: "笹田 あすか",
  }

name属性に何も指定していないので、factoryで定義した$this->faker->name()で生成されたデータが入っています。 product_idはModelの主キーであるため、factoryで定義していなくてもカラムが生成されます。

また、shop_idには「4763」という値が入っています。これが親のshop_idと同じであればリレーションデータが正しく作成されている、ということになりますので、Shop情報をtinkerで確認してみましょう。

> $product->shop

= App\Models\Shop {#29755
    shop_id: 4763,
    name: "中島 康弘",
...
  }

ProductModelインスタンスが持っているshop_idと合致するShopModelインスタンスが取得できました！ちゃんとリレーションデータが作成されていますね。

属性をオーバーライドして任意の値に

では次は、テスト用に都合のよいデータを作成するため属性値をオーバーライドしてみます。createメソッドに上書きしたいデータを配列を渡してあげます。

        $product = Product::factory()
            ->for(Shop::factory()->create([
                'shop_id' => 1,
                'name'    => 'テスト店',
            ]))
            ->create([
                'product_id' => 100,
                'name'       => 'テスト商品',
            ]);

上記をtinkerで実行すると、以下のProductModelインスタンスが作成されました。ちゃんとproduct_id、name、そしてshop_idが反映されています。

= App\Models\Product {#29799
    product_id: 100,
    name: "テスト商品",
    shop_id: 1,
...
  }

リレーション先のShopModelインスタンスも確認してみます。

> $product->shop   

= App\Models\Shop {#29774
    shop_id: 1,
    name: "テスト店",
...
  }

shop_id、nameもセットした値になっていますね。

createManyで複数データ作成

また複数のProductを一気に作る場合、createManyを使うと簡潔に記述できます。

        $products = Product::factory()
            ->for(Shop::factory()->create(
                [
                    'shop_id' => 1,
                    'name'    => 'テスト店',
                ]
            ))
            ->createMany([
                [
                    'product_id'  => 50,
                    'name'        => 'テスト商品01'
                ],
                [
                    'product_id'  => 51,
                    'name'        => 'テスト商品02',
                ],
                [
                    'product_id'  => 52,
                    'name'        => 'テスト商品03',
                ]
            ]);

tinkerの実行結果は以下のようになりました。

= Illuminate\Database\Eloquent\Collection {#29727
    all: [
      App\Models\Product {#29730
        shop_id: 1,
        product_id: 50,
        name: "テスト商品01",
        ...
      },
      App\Models\Product {#29723
        shop_id: 1,
        product_id: 51,
        name: "テスト商品02",
        ...
      },
      App\Models\Product {#29814
        shop_id: 1,
        product_id: 52,
        name: "テスト商品03",
        ...
      },
    ],

ModelではなくCollectionが返ってきています。中身にはちゃんとProductModelインスタンスが３つ入っており、shop_idも指定した通りです。

簡単にダミーデータを作成でき、テスト作成にとても便利なので是非使ってみてくださいね。

Laravel factoryでテスト用データを作成

Fri, 19 May 2023 00:04:19 +0900

テスト用のダミーデータを作成する際、factoryをよく使います。factoryを使ったダミーデータの作成方法は色々ありますが、今回は単一Modelのデータ作成でよく使う記述をご紹介します。

factoryの定義

factoryを使用するには、事前にfactoryにモデルの属性値を定義する必要があります。まず、Userモデルに対してのfactoryの定義です。

UserFactory.php

class UserFactory extends Factory
{
    public function definition()
    {
        return [
            'name'        => $this->faker->name(),
            'email'       => $this->faker->unique()->safeEmail(),
            'active_flag' => 'Y',
        ];
    }
}

作成したfactoryを対象のUserモデルへHasFactoryのトレイトで紐付すると、

User.php

use Illuminate\Database\Eloquent\Factories\HasFactory;

class User extends Model
{
    use HasFactory; //★
    ....
}

事前準備は完了です。次にテストデータを作成してみます。

テストデータの作成とDB保存

makeメソッドを使うと、インスタンスの作成のみでDBへは保存されません。

$user = User::factory()->make();

上記をtinkerで実行してみると、以下のようなインスタンスが作成されました。factoryで定義したname・email・active_flagのプロパティは、ちゃんとダミーデータになっていますね。

= App\Models\User {#29806
    name: "木村 直子",
    email: "jun.yoshida@example.com",
    active_flag: "Y",
  }

次は、インスタンスを作成しDBにも保存する場合です。createメソッドを使用します。

User::factory()->create();

tinkerでの実行結果は、以下となります。DBに保存されているので、生成されたデータにはcreated_atやupdated_atも割り当てられています。

= App\Models\User {#29843
    name: "工藤 里佳",
    email: "watanabe.rika@example.net",
    active_flag: "Y",
    updated_at: "2023-05-21 16:41:50",
    created_at: "2023-05-21 16:41:50",
    id: 21,
  }

factoryで定義していないidが割り振られているのは、Userテーブルにidカラムが主キーとして設定されているためです。

では次は、複数のデータを作成してみましょう。以下のようにfactoryに生成したい数を指定します。今回は10としました。

$users = User::factory(10)->create();

tinkerで実行した結果がこちらになります。先ほどまでと違い、返り値はCollectionとなっていますね。

= Illuminate\Database\Eloquent\Collection {#29785
    all: [
      App\Models\User {#29795
        name: "喜嶋 治",
        email: "miki66@example.org",
        active_flag: "Y",
        updated_at: "2023-05-21 17:12:34",
        created_at: "2023-05-21 17:12:34",
        id: 101,
      },
      App\Models\User {#29799
        name: "江古田 陽子",
        email: "jtsuda@example.org",
        active_flag: "Y",
        updated_at: "2023-05-21 17:12:34",
        created_at: "2023-05-21 17:12:34",
        id: 102,
      },
... 以下省略

２つ目以降の実行結果は省略しましたが、Collectionの中にUserモデルインスタンスが10生成されています。tinkerでカウントしてみると、以下のように10あるのが分かります。

> $users->count();
= 10

また、テストではプロパティを任意の値に指定したい場合が多いと思います。以下のようにcreateメソッドに配列を指定すると指定したプロパティのオーバーライドができます。

        User::factory()->create([
            'name'        => 'テストユーザー',
            'active_flag' =>  'N',
        ]);

nameとactive_flagの値を指定しました。tinkerの実行結果を見ると、ちゃんと指定した値で生成されているのがわかります。

= App\Models\User {#29789
    name: "テストユーザー",
    email: "gyamaguchi@example.net",
    active_flag: "N",
    updated_at: "2023-05-21 17:24:30",
    created_at: "2023-05-21 17:24:30",
    id: 112,
  }

いずれも最後にcreateメソッドを付けないと、データはDBに保存されないのでご注意ください。

HTTPテストでURLに日本語が含まれている場合の意図せぬ挙動

Mon, 06 Dec 2021 12:01:33 +0900

LaravelではFeatureテストが簡単に行えるように、便利なテスト用メソッドが用意されています。今回はそちらを使っていてハマってしまった意図せぬ挙動について紹介します。

HTTPテスト

例えば特定のURLにリクエストを投げ、正しいレスポンスが返されるか？などのFeatureテストをする際に、Laravelでは以下のようなテストが書けます。

tests/Feature/ExampleTest.php

<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\WithoutMiddleware;
use Tests\TestCase;

class ExampleTest extends TestCase
{
    public function test_a_basic_request()
    {
        $response = $this->get('/'); // HTTPリクエストをシミュレート

        $response->assertStatus(200); // レスポンスのステータスコードテスト

        $response->assertSee('Laravel'); // レスポンスに指定した文字列が含まれているかテスト
    }
}

上のテストでは/にGETリクエストを投げ、リクエストが正常に処理されたかステータスコード200をチェック、そして返されたレスポンスにLaravelという文字列が含まれているかをテストします。

インストール直後の状態では/にアクセスすると以下のページを返しますので、テストは成功するはずです。

URLに日本語が含まれている場合の挙動

さて、ここからが本題です。私がハマったのはURLに日本語が含まれている場合のテストです。 他の開発者のwindows環境ではパスするテストが、私のmacOS環境では必ず失敗してしまう、 という状況が発生しました。

どんなテストかを説明する為に例を用意しました。以下のようなページがあるとします。

入力した検索ワードをそのまま出力するシンプルなページです。

viewはこんな感じ。

resources/views/search.blade.php

<!DOCTYPE html>
<html lang="en">
<head>
    <title>Search</title>
</head>
<body>
    <form action="/search" method="get">
        <input type="text" name="word" value="">
        <input type="submit" value="検索">
    </form>

    <h1>{{ $word }}</h1>
</body>
</html>

routeはこんな感じ。

routes/web.php

<?php

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Route;

Route::get('/search', function(Request $request) {
    $word = $request->get('word', '');

    return view('search', compact('word'));
});

前項のExampleTestをこのページに関するテストに書き換えてみましょう。

tests/Feature/ExampleTest.php

<?php

namespace Tests\Feature;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class ExampleTest extends TestCase
{

    public function test_search_page()
    {
        $response = $this->get('/search?word=ほげ');

        $response->assertStatus(200);

        $response->assertSee('ほげ');
    }
}

“ほげ"というワードで検索した場合をシミュレートする為、/search?word=ほげにリクエストを投げ、レスポンスに文字列「ほげ」が含まれているかテストしています。

テストを実行してみましょう。

vendor/bin/phpunit --filter ExampleTest

PHPUnit 9.5.10 by Sebastian Bergmann and contributors.

.F                                                                  2 / 2 (100%)

Time: 00:00.138, Memory: 20.00 MB

There was 1 failure:

1) Tests\Feature\ExampleTest::test_search_page
Failed asserting that '<!DOCTYPE html>\n

~~省略~~

    <h1></h1>\n
</body>\n
</html>' contains "ほげ".

レスポンスに「ほげ」が含まれていない、との事でテストが失敗してしまいました。確かに、レスポンス内で検索ワードが表示される箇所が

    <h1></h1>\n

となっています。

ちなみに、検索文字列を「hoge」にした場合はパスします。

~~~
    public function test_search_page()
    {
        $response = $this->get('/search?word=hoge'); // hoge に変更

        $response->assertStatus(200);

        $response->assertSee('hoge'); // hoge に変更
    }
~~~

vendor/bin/phpunit --filter ExampleTest
PHPUnit 9.5.10 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 00:00.138, Memory: 20.00 MB

OK (2 tests, 3 assertions)

なぜでしょう？

parse_url()のバグ

$this->get()のソースを解析してみると、 vendor/symfony/http-foundation/Request.php 355行目のparse_url()にてURLからパースしたクエリ文字列が文字化けしていました。

以下はtinkerで同じコードを実行した際の結果です。

parse_url('http://127.0.0.1:8000/search?word=ほげ');
=> [
     "scheme" => "http",
     "host" => "127.0.0.1",
     "port" => 8000,
     "path" => "/search",
     "query" => b"word=ã_»ã__",
   ]

文字化けしていますね。ググってみるとGitHubで以下のIssueを見つけました。

UTF-8 URIs are broken by parse_url when locale is set

parse_url()はplatform(macなど)やlocaleの設定によってパースした文字列が壊れる場合があるとのこと。2010年から報告されているこちらのPHPのバグのようです。

urlencode()で解決

回避策として予め日本語部分をurlencode()でエンコードすれば良さそうです。 ExampleTestを以下のように修正しました。

tests/Feature/ExampleTest.php

~~~
    public function test_search_page()
    {
        $word = urlencode('ほげ');  // 予めURLエンコード

        $response = $this->get('/search?word='.$word);

        $response->assertStatus(200);

        $response->assertSee('ほげ');
    }
~~~

テストが通るようになりました。

vendor/bin/phpunit --filter ExampleTest
PHPUnit 9.5.10 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 00:00.136, Memory: 20.00 MB

OK (2 tests, 3 assertions)

まとめ

HTTPテストで日本語を含むURLにリクエストを投げる際は、日本語部分をURLエンコードするのが良さそうです。

FormRequestのユニットテスト

Sun, 18 Oct 2020 01:17:02 +0900

前回のFormRequestの入力補正を例にして、そのユニットテストを作成してみます。

ルールの部分だけのテスト

まず、テスト作成のコマンドを実行します。

$ php artisan make:test App/Http/Requests/EventRequestTest

実行すると、テストのファイルはLaravelのディレクトリ構造を真似て、tests/Feature/App/Http/Requestsのディレクトリに作成されます。

作成されたテストを以下のように編集します。

app/tests/Feature/App/Http/Requests/EventRequestTest.php

namespace Tests\Feature\App\Http\Requests;

use App\Http\Requests\EventRequest;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Tests\TestCase;

class EventRequestTest extends TestCase
{
    /**
     * @test
     * @dataProvider validationProvider
     */
    public function validation($expected, $data)
    {
        $rules = (new EventRequest())->rules(); // rules()だけを抜き出す
        $validator = validator($data, $rules);

        $this->assertEquals($expected, $validator->passes());
    }

    public function validationProvider()
    {
        return [
            [
                true,
                [
                    'start_at' => '2020-01-01 00:00:00',
                    'end_at'   => '2020-01-01 01:00:00',
                ],
            ],
            [
                false,
                [
                    'start_at' => '2020-01-01 00:00:00',
                    'end_at'   => '2020-01-01 24:00:00', // 24時はない
                ],
            ]
        ];
    }
}

実行すれば、こんな感じでパスです。あとはvalidationProvider()のテストケースを増やしていくだけです。

PHPUnit 8.5.8 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 152 ms, Memory: 22.00 MB

OK (2 tests, 2 assertions)

しかし、ちょっと待ってください!

EventRequestでは以下のようにprepareForValidation()が使用されています。つまり、実際の入力の項目（date, start_hr, end_hr）を合わせて新規の項目（start_at, end_at）を作成しています。

...
    protected function prepareForValidation()
    {
        // ここでDBに収納する項目を作成
        $this->merge([
            'start_at' => sprintf('%s %02d:00:00', $this->date, $this->start_hr),
            'end_at'   => sprintf('%s %02d:59:59', $this->date, $this->end_hr),
        ]);
    }
...

先のテストでは、ルールだけのテストなのでこの部分のテストをスキップしてしまっているのです。

ベターなテスト

やはり、直接画面から入力されるテストをしたいということで、$this->post(’/event’)とかの使用も考えましたが、DBデータを用意する必要や認証も考えてやらないやら、ちょいと面倒です。

ということで、以下の記事を見つけました。

https://dev.to/dsazup/testing-laravel-form-requests-853

これを参照して先のテストを変更しました。今度は、dateとstart_hrとend_hrがテストデータとなっていることに注意してください。

namespace Tests\Feature\App\Http\Requests;

use App\Http\Requests\EventRequest;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
use Illuminate\Validation\ValidationException;

use Tests\TestCase;

class EventRequestTest extends TestCase
{
    /**
     * @test
     * @dataProvider validationProvider
     */
    public function validation($expected, $data)
    {
       $this->assertEquals($expected, $this->validate($data));
    }

    // ここが先の記事からとってきたところ、LaravelのFormRequestServiceProvider::boot()を参照したらしい。
    protected function validate($data)
    {
        $this->app->resolving(EventRequest::class, function ($resolved) use ($data){
            $resolved->merge($data);
        });

        try {
            app(EventRequest::class);

            return true;
        } catch (ValidationException $e) {
            return false;
        }
    }

    public function validationProvider()
    {
        return [
            [
                true,
                [
                    'date'     => '2020-01-01',
                    'start_hr' => '0',
                    'end_hr'   => '1',
                ],
            ],
            [
                false,
                [
                    'date'     => '2020-01-01',
                    'start_hr' => '0',
                    'end_hr'   => '24',
                ],
            ]
        ];
    }
}

実行してみると、

PHPUnit 8.5.8 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 145 ms, Memory: 22.00 MB

OK (2 tests, 2 assertions)

うまいこと成功です！

テストにより問題発見！

テストケースを増やしてみます。

...
    public function validationProvider()
    {
        return [
...
            [
                true,
                [
                    // 同じ時間は、00:00:00と00:59:59となるのでOK
                    'date'     => '2020-01-01',
                    'start_hr' => '0',
                    'end_hr'   => '0',
                ],
           ],
           [
                false,
                [
                    'date'     => '2020-01-01',
                    'start_hr' => 'a',
                    'end_hr'   => 'b',
                ],
            ]
        ];
    }
}

PHPUnit 8.5.8 by Sebastian Bergmann and contributors.

...F                                                                4 / 4 (100%)

Time: 268 ms, Memory: 22.00 MB

There was 1 failure:

1) Tests\Feature\App\Http\Requests\EventRequestTest::validation with data set #3 (false, array('2020-01-01', 'a', 'b'))
Failed asserting that true matches expected false.

あれれ、エラーになりました。　これでは、‘2020-01-01’, ‘a’, ‘b’の入力でも正しいということになってしまいます。これはおかしい。

問題は、EventRequest::prepareForValidation()の部分で、以下のようにsprintf()で文字列が０に変換されることです。tinkerを使って検証してみると、

>>> $data = (object)['date' => '2020-01-01', 'start_hr' => 'a', 'end_hr' => 'b'];
=> {#4452
     +"date": "2020-01-01",
     +"start_hr": "a",
     +"end_hr": "b",
   }
>>> sprintf('%s %02d:00:00', $data->date, $data->start_hr, $data->end_hr);
=> "2020-01-01 00:00:00"

ゼロになっていましたね。

さて、この修正は以下となりました。start_atを作成するFormRequestの関数で、start_hr, end_hrを先にチェックして違法なら、invalidという文字列を与えることにしました。

...
   protected function prepareForValidation()
    {
        if (! preg_match('/^[0-9]{1,2}$/', $this->start_hr)) { // ２桁の数字でないときは、'invalid'とする
            $start_at = 'invalid';
        } else {
            $start_at = sprintf('%s %02d:00:00', $this->date, $this->start_hr);
        }

        if (! preg_match('/^[0-9]{1,2}$/', $this->end_hr)) {
            $end_at = 'invalid';
        } else {
            $end_at = sprintf('%s %02d:59:59', $this->date, $this->end_hr);
        }

        $this->merge([
            'start_at' => $start_at,
            'end_at'   => $end_at,
        ]);
    }
...

実行すると、今度はパスです。

PHPUnit 8.5.8 by Sebastian Bergmann and contributors.

....                                                                4 / 4 (100%)

Time: 203 ms, Memory: 22.00 MB

OK (4 tests, 4 assertions)

phpunitの実行状況表示

Mon, 03 Aug 2020 23:40:07 +0900

phpunitは私にはもう欠かせないツールなのですが、その実行をよりビジュアルに表示してくれるツールを見つけました。その紹介です。

通常は、以下のようにコマンドラインで実行すると、

$ vendor/bin/phpunit

赤字のFはFailureの失敗です。テスト数が多いと少ない表示で便利なのですが、どこでFなのかは最後まで待たないと判りません。

$ vendor/bin/phpunit --stop-on-failure

としてエラーがあったらそこで止まるというオプションもあります。しかし他のエラーもあるかもしれないし、１個のエラーを修正してまた再度テスト実行では、テストの数が多いとまどろっこしい。

$ vendor/bin/phpunit --testdox

このオプションでは以下のように実行したテストのそれぞれの詳細を出力してくれます。

いい感じですが、出力が多くてテストの数が多いと画面をスクロールするのが面倒になります。

中間というものはないかな、と調べたら、ありました。

CodeDungeon PHPUnit Pretty Result Printer

という名前のパッケージで、以下のgithubにレポジトリがあります。

https://github.com/mikeerickson/phpunit-pretty-result-printer

インストールには、以下を実行します。開発だけで使用なので、–devのオプションを忘れずに。

$ composer require --dev codedungeon/phpunit-result-printer

次に、以下を実行すると、

$ php ./vendor/codedungeon/phpunit-result-printer/src/init.php

phpunit.xmlに、printerClass=“Codedungeon\PHPUnitPrettyResultPrinter\Printer”を追加して、設定ファイル、phpunit-printer.ymlを作成します。

さて、これで再度phpunitを実行すると、

なかなか見やすいですね。

phpunitの実行のあれこれ

Sat, 08 Feb 2020 02:08:05 +0900

phpunitの実行時のオプションはいろいろあります。今回は私が便利！と思ったオプションを紹介します。

まず、testsのディレクトリの構造が以下と仮定します。

tests
├── CreatesApplication.php
├── Feature
│   └── ExampleTest.php
├── TestCase.php
└── Unit
    ├── ExampleTest.php
    └── UserTest.php

オプションなしでphpuitを実行すると、tests/Unit, tests/Featureのディレクトリのファイル名ががTest.phpで終わるファイルに含まれるテストすべてを実行します。

$ vendor/bin/phpunit                          
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

...                                                                 3 / 3 (100%)

Time: 621 ms, Memory: 24.00 MB

OK (3 tests, 3 assertions)

どのテストが実行されるかは、–list-testsのオプションで出力してくれます。

$ vendor/bin/phpunit --list-tests
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

Available test(s):
 - Tests\Unit\ExampleTest::testBasicTest
 - Tests\Unit\UserTest::test_create_a_user
 - Tests\Feature\ExampleTest::testBasicTest

実行しながら、どのテストが実行されるのを見たいなら、–testdoxのオプションを付けます。注意：以下のそれぞれのテストでのxは成功という意味で、実際には✔で表示されます。コードのセクションではエスケープされるので置き換えています。

$ vendor/bin/phpunit --testdox       
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

Example (Tests\Unit\Example)
 x Basic test

User (Tests\Unit\User)
 x Create a user

Example (Tests\Feature\Example)
 x Basic test

Time: 582 ms, Memory: 24.00 MB

OK (3 tests, 3 assertions)

特定のファイルに含まれるテストのみを実行したいなら、以下のようにファイル名を指定します。

$ vendor/bin/phpunit tests/Feature/ExampleTest.php

あるいは、テスト名のみでもＯＫです。

$ vendor/bin/phpunit tests/Feature/ExampleTest

実行したいテストをパターンで指定することも可能です。

例えば、Exampleから始まるテストファイルだけを実行したいなら、以下のように、–filterオプションを使用します。

$ vendor/bin/phpunit --filter Example --testdox   
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

Example (Tests\Unit\Example)
 x Basic test

Example (Tests\Feature\Example)
 x Basic test

Time: 323 ms, Memory: 16.00 MB

OK (2 tests, 2 assertions)

Exampleで始まるテストファイル名は、UnitとFeatureに存在するので両方が実行されます。

テストファイルに含まれる、テスト名の指定も可能です。

$ vendor/bin/phpunit --filter testBasicTest --testdox
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

Example (Tests\Unit\Example)
 x Basic test

Example (Tests\Feature\Example)
 x Basic test

Time: 304 ms, Memory: 16.00 MB

OK (2 tests, 2 assertions)

testBasicTestのテストは、これまたUnitとFeatureのExampleTest.phpに存在するので両方が実行されます。

特定のファイルの特定のテストだけを実行したいなら、以下のようにテスト名とパス名を指定します。

$ vendor/bin/phpunit --filter testBasicTest tests/Unit/ExampleTest.php --testdox
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

Example (Tests\Unit\Example)
 x Basic test

Time: 148 ms, Memory: 6.00 MB

OK (1 test, 1 assertion)

オプションなしでのphpunitの実行は、phpunit.xmlのtestsuitesの編集で変更することが可能です。以下はデフォルトの設定です。

phpunit.xml

...
    <testsuites>
        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>

        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>
    </testsuites>
..
</phpunit>

現在２つのtestsuiteが存在しますが、Unitの方だけを実行したいなら、

$ vendor/bin/phpunit --testsuite Unit --testdox
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

Example (Tests\Unit\Example)
 x Basic test

User (Tests\Unit\User)
 x Create a user

Time: 523 ms, Memory: 22.00 MB

OK (2 tests, 2 assertions)

と指定できます。

現在、私のあるプロジェクトではdbunitを使用するテストからRefreshDatabaseを使用するテストに書き換えています。新旧のテストを別々にテストしたいために、phpunit.xmlは以下のように４つのtestsuiteが存在します。

    <testsuites>
        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
            <exclude>./tests/Feature/Http</exclude>
        </testsuite>
        <testsuite name="Http">
            <directory suffix="Test.php">./tests/Feature/Http</directory>
        </testsuite>
        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
            <exclude>./tests/Unit/Models</exclude>
        </testsuite>
        <testsuite name="Models">
            <directory suffix="Test.php">./tests/Unit/Models</directory>
        </testsuite>
    </testsuites>

excludeのタグを使用することで、サブディレクトリのテストを非実行とできます。

実行は以下のように２つ実行します。

$ vendor/bin/phpunit --testsuite Feature,Unit
$ vendor/bin/phpunit --testsuite Models,Http

データベースのテスト

Sat, 01 Feb 2020 02:18:37 +0900

既存のDBのそれぞれのテーブルにおいて、migrationファイルやfactoryファイルが揃ったところで、phpunitのテストを作成して実行してみましょう。

テストDBの作成

テストDBは、phpunitのためだけのDBとなるゆえに、ブラウザでアクセスする本DBとは違うDBを作成します。つまり、開発サイトでは、プロジェクト１つに対して２つのDBを持つことになります。

本DBは、mysqlで、テストのDBには、sqliteという設定がドキュメントでも一般のLaravelの記事でも書かれていますが、私はテストといえども、本DBもテストDBも同じmysqlを使用することを勧めます。条件をまったく同じとしたいからです。

まず、mysqlのコマンドで、テストDB（demo_test）を作成します。

$ echo "create database demo_test" | mysql -u root -p
Query OK, 1 row affected (0.00 sec)

次に、config/database.phpをエディターで開いて、mysqlのコネクションをコピーして、mysql_testのコネクションを作成します。

config/databse.php

use Illuminate\Support\Str;

return [
....
    'connections' => [
...
        'mysql' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => env('DB_DATABASE', 'forge'),
            'username' => env('DB_USERNAME', 'forge'),
            'password' => env('DB_PASSWORD', ''),
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            '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_test' => [
            'driver' => 'mysql',
            'url' => env('DATABASE_URL'),
            'host' => env('DB_HOST', '127.0.0.1'),
            'port' => env('DB_PORT', '3306'),
            'database' => 'demo_test',
            'username' => 'root',
            'password' => 'secret',
            'unix_socket' => env('DB_SOCKET', ''),
            'charset' => 'utf8mb4',
            '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_testにおいて編集した項目は、database、username、passwordです。env()を使用せずに、固定としています。必要なら他の項目も同様に編集してください。それから、usernameに指定するmysqlのユーザーは必ず、drop table, create table, truncateのsql文と実行できる権限を持つユーザーである必要があります。それゆえに、ここではrootのmysqlユーザーを使用しています。

次に、テーブル作成のartisanコマンドを実行して、テストDBにテーブルを作成します。前回で作成したmigrationファイルがここで役立ちます。

$ php artisan migrate:fresh --database=mysql_test
Dropped all tables successfully.
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (0.03 seconds)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table (0.02 seconds)
Migrating: 2019_08_19_000000_create_failed_jobs_table
Migrated:  2019_08_19_000000_create_failed_jobs_table (0.01 seconds)

必ず、–databaseでmysql_testのコネクションを指定ください。指定しないと、本DBの方が空となってしまうので注意を！

phpunitの設定

テストDBをテストの実行で使用するには、phpunit.xmlの編集が必要です。

phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="./vendor/phpunit/phpunit/phpunit.xsd"
         backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="vendor/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>

        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist processUncoveredFilesFromWhitelist="true">
            <directory suffix=".php">./app</directory>
        </whitelist>
    </filter>
    <php>
        <server name="APP_ENV" value="testing"/>
        <server name="BCRYPT_ROUNDS" value="4"/>
        <server name="CACHE_DRIVER" value="array"/>
        <server name="DB_CONNECTION" value="mysql_test"/>
        <server name="MAIL_DRIVER" value="array"/>
        <server name="QUEUE_CONNECTION" value="sync"/>
        <server name="SESSION_DRIVER" value="array"/>
    </php>
</phpunit>

DB_CONNECTIONをmysql_testと指定しています。

さて、これでphpunitを実行できます。vendor/bin/phpunitは、このプロジェクトでインストールされたバージョンのphpunitなので、必ずそのパスを使用してください。

$ vendor/bin/phpunit
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 335 ms, Memory: 16.00 MB

OK (2 tests, 2 assertions)

OKがテスト成功、という意味です。

RefreshDatabaseトレイト

先のphpunitの実行では、データベースのテストは含まれていません。作成してみましょう。

$php artisan make:test --unit UserTest
Test created successfully.

この実行で、tests/Unit/UserTest.phpのファイルが作成されますが、それを以下のように編集します。

UserTest.php

namespace Tests\Unit;

// use PHPUnit\Framework\TestCase // Laravel 6.xで生成されるが、コメントして以下を追加
use Tests\TestCase;

use Illuminate\Foundation\Testing\RefreshDatabase; // 追加

use App\User;

class UserTest extends TestCase
{
    use RefreshDatabase;

    public function test_create_a_user()
    {
        factory(User::class)->create(); // usersのDBテーブルにレコードを１つ作成

        $this->assertCount(1, User::all()); // すべてのレコードを取得してレコード数が１であることを確認
    }
}

実行してみましょう。

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)

成功ですね。

このテストは何回実行しても成功となります。

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)
$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)

試しに、use RefershDatabaseをコメントして実行してみてください。

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 511 ms, Memory: 22.00 MB

OK (1 test, 1 assertion)

$ vendor/bin/phpunit --filter UserTest
PHPUnit 8.5.2 by Sebastian Bergmann and contributors.

F                                                                   1 / 1 (100%)

Time: 324 ms, Memory: 18.00 MB

There was 1 failure:

1) Tests\Unit\UserTest::testExample
Failed asserting that actual size 2 matches expected size 1.

/vol1/usr/www/repos/repos/l6x/tests/Unit/UserTest.php:23

FAILURES!
Tests: 1, Assertions: 1, Failures: 1.

１回名は成功ですが、２回目は失敗です．なぜなら、RefereshDatabaseなしではレコードは追加されていくばかりだからです。RefereshDatabaseのトレイトを使用することによりDBテーブルが空となり、毎回同じ条件でテストを実行できます。

既存のDBからfactoryファイルを自動作成

Sat, 25 Jan 2020 07:51:08 +0900

既存のＤＢからmigrationファイルを自動作成によって、テストのために空のDBテーブルの作成が可能となりました。今度は、そこへテストデータを作成するためにfactoryが必要となります。これも自動作成しましょう。

どうして、factoryのファイルが必要？

factoryのファイルが必要なのは、あらゆるテストの目的のためです。いちいち画面の入力でDBレコードを作成する代わりに、tinkerやユニットテストでfactory()のヘルパーを使用して簡単にレコードが作成できようになります。factoryのタグの記事では、たくさんの使用例を見ることできます。

しかし、現状の以下のLaravelのコマンドの実行では、

$ php artisan make:factory UserFactory --model=User

作成されるfactoryは、以下のように項目もない単なるテンプレートです。

databases/factorys/UserFactory.php

/** @var \Illuminate\Database\Eloquent\Factory $factory */

use App\Model;
use Faker\Generator as Faker;

$factory->define(User::class, function (Faker $faker) {
    return [
        //
    ];
});

DBテーブルがたくさんあるプロジェクトでは、いちいちこれを編集していくのはとても大変です。それゆえに、既存のDB構造をもとに、自動でfactoryファイルを生成する必要があります。

factoryファイル自動生成ツール

まずは、パッケージのインストール。以下をコマンドラインで実行します。

$ composer require --dev mpociot/laravel-test-factory-helper

factoryのファイルを作成するには、artisanの実行が必要となります。Laravel 6.x の新規プロジェクトを作成して実行しますが、すでにUserのモデルのためのfactoryファイルが、databases/factories/UserFactory.phpとして存在するので、上書きされないように改名しておきます。そして以下をコマンドラインで実行します。

$ php artisan generate:model-factory
Model factory created: database/factories/UserFactory.php

作成されたfactoryの内容は以下です。

databases/factories/UserFactory.php

/* @var $factory \Illuminate\Database\Eloquent\Factory */

use Faker\Generator as Faker;

$factory->define(App\User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->safeEmail,
        'email_verified_at' => $faker->dateTime(),
        'password' => bcrypt($faker->password),
        'remember_token' => Str::random(10),
    ];
});

元にあったファイルと比べてみましょう。以下が元のファイルです。

/** @var \Illuminate\Database\Eloquent\Factory $factory */

use App\User;
use Faker\Generator as Faker;
use Illuminate\Support\Str;

$factory->define(User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->unique()->safeEmail,
        'email_verified_at' => now(),
        'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
        'remember_token' => Str::random(10),
    ];
});

いくつか違いがありますね。しかし、これも自動生成されたmigrationファイルと同様に使用するテストに合わせて編集すればよいです。 Fakerのドキュメントは、こちらです。

factoryファイル自動作成のコマンドのartisanの実行には、いくつかのオプションを指定することができます。

すべてのモデルのfactoryを作成する代わりに、指定のモデルだけのfactoryの作成には、

$ php artisan generate:model-factory User Team

モデルのファイルがが、app/Modelsのディレクトリにあるなら、

$ php artisan generate:model-factory --dir app/Models -- User Team

と実行できます。

最後に、migrationとfactoryの自動作成ツールは、Laravelのバージョンによりインストールが違うのでここでまとめてリストします。

Laravel 6.x

$ composer require --dev oscarafdev/migrations-generator 2.0.13
$ composer require --dev mpociot/laravel-test-factory-helper

Laravel 5.5~

$ composer require --dev xethron/migrations-generator
$ composer require --dev mpociot/laravel-test-factory-helper v1.3

Larave 6.xへ更新

Sat, 18 Jan 2020 01:14:39 +0900

またまたLaravelの更新の時期がやってきました。と言っても、またしても遅れての私のキャッチアップです。Laravel 6.xのバージョンは、Laravel 5.5と同様にLTSの長期サポートまでなので、バグの修正は、9/3/2021まで、セキュリティの修正は、9/3/2022までとあるので、できるならアップグレードしたいです。また、6.xのバージョンは、新サービスのサーバーレス対応のVaporでは必須ゆえに、Laravelを実行するサーバーのスケールアップに興味があるなら、なおさら頑張ってアップグレードする必要あります。

何が変わった？

さて、バージョン6.xともなると、大きな変更は少なくなってきています。私のプロジェクトでのアップグレードで気づいたことの報告をします。

まず忘れる前に、Laravel 6.xの更新には、最低php 7.2のバージョンが必要となります。と言っても、最新のphpは、バージョン7.4です。phpもLaravelもバージョンアップのペースが速い。もう少し遅くても、とも思います。

ヘルパーの変更

Laravel 5.8に更新で登場したのですが、配列や文字列のヘルパー関数が、クラスのstaticのメソッドに代わる、という話。例えば、array_only()は、Arr::only()に代わる。その時点では、両方使用できましたが、Laravel 6.xでは、もうグローバル関数の方はデフォルトでは使用できません。

それらを使用するには、以下を実行してパッケージを追加する必要あります。

$ composer require laravel/helpers

使用していたパッケージへの影響

phpunitのバージョンは、Laravel 5.8のバージョン7からバージョン8になりました。そして悲しいことに私が愛好していたデータベースのテストのphpunit/dbunitの開発・管理が止まりました。

ここでいつか紹介しようと思っていたのですが、紹介する前に作者の意向で開発ストップです。dbunitは、xmlファイルで用意したデータをユニットテストのためにデータベースにインポートしてくれる便利な機能があります。毎回のテストの前には、データをtruncateしてくれるのでいつでも空の状態から始めることができ、でテストの再現性を実現してくれます。

しかし、そこはオープンソースの強みというか、githubなどのサービスの便利さというか、他の開発者（以下のリンク）が早速にもレポをフォークしてphpunitバージョン8に対応してくれています。残念ながら、このパッケージのメインテナーとはならないようですが。

https://github.com/kornrunner/dbunit

これで暫くは凌げそうですが、この際に、Laravelのmigrationやfactoryを使用した、RefershDatabaseのトレイトを使ったデータベースのテストに書き換えていこうとも思います。

そして、そのステップ１として、前回の既存のＤＢからmigrationファイルを自動作成のパッケージの紹介でした。

しかし、このパッケージ、残念ながらLaravel6.xでは互換性で使えない、と思ったら対応しているこれまたレポをフォークしたパッケージがありました。

https://github.com/oscarafdev/migrations-generator

捨てる神があれば、拾う神ありです。助けられます。

ユーザー認証

Laravel 5.xでは、php artisan make:authの実行でユーザー認証の機能が追加できました。

Laravel 6.xでは、以下の実行が必要となります。

$ composer require laravel/ui
$ php artisan ui bootstrap --auth

uiのタイプとしては、bootstrap, vue, reactの選択があります。これらの実行で、ユーザー認証に必要なrouteの追加や、コントローラーやブレードのファイルが作成されます。

バリデーションの実例：条件付きの必須

Sun, 07 Oct 2018 09:55:41 +0900

今回は、他の項目により対象の項目が必須となるかどうかのルールを紹介します。

required_if required_unless required_with required_with_all required_without required_without_all

バリデーションの実例：DBの情報を引数とする条件

Sun, 29 Jul 2018 05:10:01 +0900

今回は、引数にDBの情報を指定するバリデーションルールです。今回はデータベースを伴うテストなので、use RefreshDatabase;のトレイトや、factory()->create()が使用されています。

exists unique

後者の方は、会員登録では必須のバリデーションです。会員編集の方でも自分のレコードを外す引数を指定すれば使用可能です。しかし、Laravel 5.5からのRuleの登場で、よりわかりやすい形でも指定できます。これらは皆、今回のテストに含まれています。

バリデーションの実例：他の項目の値を引数とする条件

Sun, 22 Jul 2018 04:08:56 +0900

今回は、引数にフォームの他の項目名を指定するバリデーションルールです。

confirmed different in_array same

個人的には、最初のconfirmed以外は使用したことないですね。in_arrayでは引数として指定する項目が配列であることを示すために、field2.*のように指定する必要あることに注意してください。

さて、他の項目の値を引数としては使わないのですが、入力値が配列のときに、それらの値に重複がないというチェックもここに掲載します。他に入れるところがないというのですが、本当は。配列という投稿を作成してもよいかもしれませんね。

distinct

バリデーションの実例：定数値を引数とする条件

Sun, 15 Jul 2018 07:22:29 +0900

入力値のデータタイプの判定のバリデーションから、今度は条件で判定するバリデーションに移っていきます。条件で判定するバリデーションには、その条件で使用される引数の指定が必要となります。引数には、

文字列や数字の定数値（例：min, maxなど）
同じフォームの他の項目名（例：same、differentなど）
DBの情報（例：exists、unique）

が指定されます。

今回は、最初の引数タイプ、定数値を引数とする条件の以下のバリデーションのテストを掲載します。

digits digits_between size between min max in not_in regex

また、前回紹介した日付のバリデーションの以下も定数値を引数とする条件に含まれますね。

date_format, date_equals, after, after_or_equal, before, before_or_equal

今回の注意点は、size, between, min, maxにおいて、入力値を文字列でなく数値として扱うには、numericあるいはintegerのルールの指定が必要なことです。例えば、integer|between:3,10なルールになります。

バリデーションの実例：日付

Sat, 07 Jul 2018 07:11:01 +0900

今回は日付関連のバリデーションを掲載します。

date date_format date_equals after after_or_equal before before_or_equal

date以外、今回は皆ルールの指定にはパラメータが必要となります。

バリデーションの実例：特殊データタイプ

Sun, 01 Jul 2018 05:57:20 +0900

特殊データタイプとしてのチェックとして以下のテストを掲載します。以下からのリンクだけでなく、この投稿にも掲載してあります。

alpha alpha_dash alpha_num accepted active_url email ip timezone url

今回、まず注意する必要があるのは、alpha, alpha_dash, alpha_numです。これらの「アルファ」は通常の半角英字と仮定してしまいますが、実際はそれぞれの言語でのアルファベット、という意味で、英語ではなく一般的に言語の文字列という意味です。つまり、日本語なら何でもＯＫということになります。ログインなどに使用する半角英数字のアルファベットのバリデーションには、これでなくユーザー定義が必要となりますね。

それから、emailのバリデーション、日本のユーザーに対応するならRFC非準拠のメールアドレス（「.」を「..」などのように連続で使用することや@マークの直前で使用）は対応していません。これも、ユーザー定義のバリデーションが必要となります。

バリデーションの実例：基本データタイプ

Sun, 24 Jun 2018 01:22:59 +0900

基本データタイプのチェックとして以下のテストを掲載します。以下からのリンクだけでなく、この投稿にも掲載してあります。

boolean integer numeric string array json

dateも入れようかと思いましたが、その他の日付関連のバリデーションとともに掲載します。

以下の掲載で説明が必要な部分は、ブーリアンです。入力値がfalseなのにどうしてtrueを返すのか？データをチェックしているのでなく、データがブーリアンタイプであるかをチェックしている、と考えてください。

それから、配列のテストで、どうして空の[]がrequiredによりエラーとなりますが、jsonの{}はエラーとならないのかは謎です。

バリデーションの実例

Sun, 17 Jun 2018 05:54:57 +0900

新しい連載を始めます。

Laravelは、出来合いのヘルパーやバリデーションがあり便利です。もの凄くたくさんあり覚えらないというほどの数ではないですが、すべてを頭の中で保持しておくのも大変です。また、こういう使い方では結果はどうなるのとか、実際に実行してみないとわからないことあります。

例えば、バリデーションのalphaは、文字列がすべて英字からなる（本当？）かをチェックします。このバリデーションを、ログイン名のチェックとかに使うとします。しかし、大文字でもＯＫなのとか、空白文字が入ってもＯＫなのとか、日本語の入力はどうなのとか、調べないとわからないことあります。Laravelのドキュメントではそこまで細かくは説明していません。

前回で説明したようにtinkerで簡単にチェックすることも可能ですが、面倒だなと思うときに、実例を素早く見ることができれば便利だと思いません？

そこで今回から、そんな便利な実例特集を連載する予定です。まず、その１つを見てください。以下は、Laravelのバリデーションのacceptedのユニットテストです。

実例の使い方

先に掲載したコードは、github.comのgistを使用しています。gistは、一般的にスニペットと言われる、コピペ専用が目的のgitのレポジトリです。gitでコード管理するのと同様、cloneやforkの利用も可能です。

上のコードを実際にテストしてみたいなら、ララベル5.5のプロジェクトを作成して、そのプロジェクトのルートのディレクトリで、以下を実行してください。

$ git clone git@gist.github.com:cf781699c05c73d07fdbff8489052ef8.git tests/Unit/Validations/Accepted

コマンドラインで指定したURLは、

gistの画面において、embedのドロップダウンのリストから、Clone via SSHを指定して、表示されたURLを使います。以下の画面では、赤いボックスのところをクリックしてコピーできます。

コマンドの実行は、以下のように、tests/Unit/Validations/Acceptedのディレクトリを作成して、テストのファイルを作成してくれます。

tests/Unit
├── ExampleTest.php
└── Validations
    └── Accepted
        ├── 0.md
        └── AcceptedTest.php

ダウンロードしたところで、テストを実行してみましょう。

$ vendor/bin/phpunit --filter AcceptedTest
PHPUnit 6.5.8 by Sebastian Bergmann and contributors.

.........                                                           9 / 9 (100%)

Time: 201 ms, Memory: 12.00MB

OK (9 tests, 9 assertions)

と９つテストがすべて成功の結果を表示してくれます。

phpunitのデータプロバイダー

先のテストの実行では、９つのテストが成功、とありましたが、９つのテストなるゆえは、上のコードのprovider_acceptedの関数内に９つのデータ配列があるからです。

このユニットテストでは、phpunitのデータプロバイダー機能を使用しています。その機能では、コメントに入れる情報で、どこからデータを受け取るかを指定します。

    /**
     * @test ←　関数がテストの関数であることを指定
     * @dataProvider provider_accepted　←　この関数からデータを取ってくることを指定
     */
    public function accepted($input, $expected)
    {
     ..

provider_accepted()では、

例えば、最初のデータ

[[‘field’ => null], false]

は、

[‘field’ => null]　が　accepted()の最初のパラメの$input

となり、

falseが、$expected

となります。

テストの実行では、９つのデータ配列があるので、データを変えて9回のテストの実行となります。そして、さらにいろいろテストしたいなら、そのデータと期待する結果をそこに追加すればよいだけです。

バリデーションの実例の連載開始

ということで、次回からバリデーションの実例を投稿していきます。まずは、Laravelにある規定のバリデーションですが、それだけでなくユーザー定義のバリデーションもアップしていく予定です。

ユーザー認証のテスト(4) Laravel 5.4　パスワードリセット

Sat, 05 May 2018 06:07:34 +0900

今回はパスワードのリセットのテストです。

パスワードのリセットは、以下のステップがあります。

パスワードリセットのリクエスト画面へ行き、Eメールアドレスを入力してリセットをリクエスト
メールでパスワードリセットのトークン付きのURLを受信
パスワードリセット画面へ行きパスワードをリセット

テストケースとして考えられるのは、

パスワードリセットリクエスト画面へのアクセスができる
登録された会員のEメールアドレスでパスワードのリセットのリクエストが成功がする
登録されていない会員のEメールアドレスでパスワードのリセットのリクエストが失敗
成功したパスワードのリセットのリクエストで受信したURLでパスワードリセットの画面にアクセスができる
その画面でパスワードリセットができる

パスワードリセットリクエスト画面でのテスト

まずは、画面にアクセスできることを確認。

tests/Features/ResetPasswordTest.php

   /**
     * @test
     * パスワードリセットをリクエストする画面の閲覧可能
     */
    public function user_can_view_reset_request()
    {
        $response = $this->get('password/reset');

        $response->assertStatus(200);
    }

そして、画面にEメールアドレスを入力して、成功のメッセージが表示されることを確認。

tests/Features/ResetPasswordTest.php

   /**
     * @test
     * パスワードリセットのリクエスト成功
     */
    public function valid_user_can_request_reset()
    {
        // ユーザーを1つ作成
        $user = factory(User::class)->create();

        // パスワードリセットをリクエスト
        $response = $this->from('password/email')->post('password/email', [
            'email' => $user->email,
        ]);

        // 同画面にリダイレクト
        $response->assertStatus(302);
        $response->assertRedirect('password/email');
        // 成功のメッセージ
        $response->assertSessionHas('status',
            'リクエストを受け付けました。パスワードの再設定方法をメールでお知らせします。');
    }

ここで注目することとして2点。

まず、$this->from(‘password/email’)->postで使用されているfrom()。これがないと、 $response->assertRedirect(‘password/email’);以下のようなエラーとなります。

There was 1 failure:

1) Tests\Feature\ResetPasswordTest::valid_user_can_request_reset
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'http://localhost/password/email'
+'http://localhost'

この画面では成功時には、back()で前の画面に戻されます。しかし、テストでは前の画面の場所は保存していないので、デフォルトのホーム/になります。password/emailに戻るには、セッションあるいはリファラーで前の画面のURIを記録しておく必要があります。以下のように、TestCase.phpにfrom()の定義をしておきます。

tests/TestCase.php

namespace Tests;

use Illuminate\Foundation\Testing\TestCase as BaseTestCase;

abstract class TestCase extends BaseTestCase
{
    use CreatesApplication;

   /**
     * Set the referer header to simulate a previous request.
     *
     * @param  string  $url
     * @return $this
     */
    public function from(string $url)
    {
    	session()->setPreviousUrl(url($url));
        return $this;
    }
}

次に注目してもらいたいのは、成功のメッセージが表示されるかどうかのチェック。これは、セッションにstatusのキーが含まれているかどうかをチェックします。成功時には以下のメソッドでstatusにレスの文字列がセッションを介して保存されます。

vendor/laravel/framework/src/Illuminate/Foundation/Auth/SendsPasswordResetEmails.php

    /**
     * Get the response for a successful password reset link.
     *
     * @param  string  $response
     * @return \Illuminate\Http\RedirectResponse
     */
    protected function sendResetLinkResponse($response)
    {
        return back()->with('status', trans($response));
    }

このリクエスト画面で、今度は失敗するケース。単に、存在しない会員のEメールアドレスを入力してみます。今度は、セッションに含まれるerrorsに、emailのエントリがあるかをチェックして確認です。

tests/Features/ResetPasswordTest.php

   /**
     * @test
     * 存在しないメールアドレスでパスワードリセットのリクエストをして失敗
     */
    public function invalid_user_cannot_request_reset()
    {
        // ユーザーを1つ作成
        $user = factory(User::class)->create();

        // 存在しないユーザーのメールアドレスでパスワードリセットをリクエスト
        $response = $this->from('password/email')->post('password/email', [
            'email' => 'nobody@example.com'
        ]);

        $response->assertStatus(302);
        $response->assertRedirect('password/email');
        // 失敗のエラーメッセージ
        $response->assertSessionHasErrors('email',
            '指定のメールアドレスは見つかりませんでした');
    }

パスワードリセット画面でのテスト

今度はリクエストではなく、実際にパスワードをリセットする画面に関してのテストです。このテストは２つの部分からなります。

パスワードリセットをリクエストした後に受信するEメールのURLをもとに、パスワードリセット画面にアクセスできるかを確認
その画面でパスワードを更新可能なことを確認

少しコードは長くなりますが、まさしくユーザーが辿るステップをそのままここで実現します。

tests/Features/ResetPasswordTest.php

   /**
     * @test
     * パスワードリセットのトークンでパスワードをリセット
     */
    public function valid_user_can_reset_password()
    {
        Notification::fake();

        // ユーザーを1つ作成
        $user = factory(User::class)->create();

        // パスワードリセットをリクエスト
        $response = $this->post('password/email', [
            'email' => $user->email
        ]);

        // トークンを取得

        $token = '';

        Notification::assertSentTo(
            $user,
            ResetPassword::class,
            function ($notification, $channels) use ($user, &$token) {
                $token = $notification->token;
                return true;
            }
        );

        // パスワードリセットの画面へ
        $response = $this->get('password/reset/'.$token);

        $response->assertStatus(200);

        // パスワードをリセット

        $new = 'reset1111';

        $response = $this->post('password/reset', [
            'email'                 => $user->email,
            'token'                 => $token,
            'password'              => $new,
            'password_confirmation' => $new
        ]);

        // ホームへ遷移
        $response->assertStatus(302);
        $response->assertRedirect('/home');
        // リセット成功のメッセージ
        $response->assertSessionHas('status', 'パスワードはリセットされました!');

        // 認証されていることを確認
        $this->assertTrue(Auth::check());

        // 変更されたパスワードが保存されていることを確認
        $this->assertTrue(Hash::check($new, $user->fresh()->password));
    }

まず、最初パートでは、リクエストで送信されたEメールに含まれるトークン付きのURLを取得する必要あります。それがなければ、リセット画面にアクセスできません。送信したメールをログにしてそれを読み込んで、URLで抽出ということも可能です。しかし、ここではNotification::fakeを利用することによって、綺麗に簡単に、トークンを抽出します。

そして、そのトークンを利用してリセット画面でEメールアドレスを更新します。更新成功後では、

リセット成功のメッセージが画面に表示されること
ユーザが認証されていること
更新されたパスワードが保存されていること

を確認します。更新されたパスワードを取得するのに、$user->passwordでなく、$user->fresh()->passwordとなっていることに注意してください。fresh()により、$userのオブジェクトの中身が更新されます。

他に考えられるテストは？

以上のテストで十分と思われるかもしれませんが、テストケースは切りがないほど考えられます。例えば、

期限切れのトークンでリセット画面にアクセスしたとき
有効のトークンでアクセスして、トークンを発行したものと違うとEメールアドレスを入力したとき
リセットの画面でパスワードと確認パスワードが異なるとき

などなど。

最後に今回のテストのコードは以下から利用可能です。

https://github.com/lotsofbytes/larajapan/blob/5.4-test/tests/Feature/ResetPasswordTest.php

ユーザー認証のテスト(3) Laravel 5.4　ログアウト

Sat, 10 Feb 2018 03:02:18 +0900

前回のログインのテストに対して、今回はログアウトのテスト。

まず、以下を見てください。

   /** @test */
    public function logout()
    {
        // ユーザーを１つ作成
        $user = factory(User::class)->create();

        // 認証済み、つまりログイン済みしたことにする
        $this->actingAs($user);

        // 認証されていることを確認
        $this->assertTrue(Auth::check());

        // ログアウトを実行
        $response = $this->post('logout');

        // 認証されていない
        $this->assertFalse(Auth::check());

        // Welcomeページにリダイレクトすることを確認
        $response->assertRedirect('/');
    }

前回と違うのは、ログインの実行$response = $this->post(..)が今回のテストにはないことです。その代わりに、actingAs()を利用して、プログラムで認証済みにしてしまいます。

actingAs()のおかげで、コードが短くなりわかりやすくなっただけでなく、その使用では以下のようにセッション値を入れたり、リダイレクトすることも可能です。認証された後の、つまりパスワード保護された中の機能のテストではいつも必要なことなので、将来重宝しそうです。

..
 $response = $this->actingAs($user)
                   ->withSession(['foo' => 'bar'])
                   ->get('/');
...

さて、テストとは関係ないですが、ログアウト後はどうして、/loginでなく/にリダイレクトされるのでしょう？また、その変更は可能なのでしょうか？

リダイレクト先は、残念ながら、以下のlaravelのパッケージの中のファイルでハードコードされています。

vendor/laravel/framework/src/Illuminate/Foundation/Auth/AuthenticateUsers.php

...
   /**
     * Log the user out of the application.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\Response
     */
    public function logout(Request $request)
    {
        $this->guard()->logout();

        $request->session()->invalidate();

        return redirect('/');
    }
...

上のファイルは編集するべきではありません。しかし、ログアウト後のリダイレクト先を変更したいなら、

app/Http/Controllers/Auth/LoginController.php

に、上のlogoutのコードを追加して、リダイレクト先を編集すればよいです。親のメソッドが上書きされて変更されることになります。use Illuminate\Http\Request;の行の追加も忘れないように。以下に全コードを掲載します。

LoginController.php

namespace App\Http\Controllers\Auth;

use App\Http\Controllers\Controller;
use Illuminate\Foundation\Auth\AuthenticatesUsers;
use Illuminate\Http\Request;

class LoginController extends Controller
{
    /*
    |--------------------------------------------------------------------------
    | Login Controller
    |--------------------------------------------------------------------------
    |
    | This controller handles authenticating users for the application and
    | redirecting them to your home screen. The controller uses a trait
    | to conveniently provide its functionality to your applications.
    |
    */

    use AuthenticatesUsers;

    /**
     * Where to redirect users after login.
     *
     * @var string
     */
    protected $redirectTo = '/home';

    /**
     * Create a new controller instance.
     *
     * @return void
     */
    public function __construct()
    {
        $this->middleware('guest')->except('logout');
    }

    /**
     * Log the user out of the application.
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\Response
     */
    public function logout(Request $request)
    {
        $this->guard()->logout();

        $request->session()->invalidate();

        return redirect('/');
    }
}

最後に今回のテストのコードは以下から利用可能です。

https://github.com/lotsofbytes/larajapan/blob/5.4-test/tests/Feature/LoginTest.php

ユーザー認証のテスト(2) Laravel 5.4　ログイン

Wed, 07 Feb 2018 00:21:29 +0900

前回は、

ログイン画面にアクセスできる
ログインしないで、ホームページにアクセスするとログイン画面にリダイレクトされる

のテストを作成しました。

今回は、同じくログイン画面において以下のテストを作成します。

登録されているユーザーのＥメールとパスワードでログインできる
間違ったパスワードでログインした場合、ログイン失敗してエラーが出力される

モデルファクトリ

さて、前回と違って今回は、ログインのテストゆえにテストのデータベースにユーザーのレコードが必要となります。もちろん、手動でレコードを作成しておいてテストも可能です。しかし、テストが複雑になって様々なケースのテストが増えてくると非常に面倒です。

そこで登場するのは、モデルファクトリ。テストのために、必要なデータを必要な数だけ自動生成してDBレコードを作成してくれます。ファクトリの設定は、LaravelのEloquentのモデルを指定するのでとても簡単。以下ではUserのモデルをもとにしています。Fakerのパッケージを利用しているので各項目での詳細はそちらを参照してください。

database/factories/ModelFactory.php

use Faker\Generator as Faker;

/** @var \Illuminate\Database\Eloquent\Factory $factory */
$factory->define(App\User::class, function (Faker $faker) {
    static $password;

    return [
        'email'          => $faker->unique()->safeEmail, // 複数レコード作成時には重複しないＥメールを生成
        'password'       => $password ?: $password = bcrypt('test1234'),　// 複数レコード作成時には同じパスワードを生成
        'name'           => $faker->name,
        'remember_token' => str_random(100),　//ランダム値
    ];
});

上の設定では、複数のレコード作成時には、emailは重複しないように、パスワードはstatic変数を利用してどのレコードも同じパスワードを作成するようなっています。bcryptは、LaravelのヘルパーでHash::makeと同じです。

日本語のデータを生成したいなら、config/app.phpで、

config/app.php

..
    /*
    |--------------------------------------------------------------------------
    | Application Locale Configuration
    |--------------------------------------------------------------------------
    |
    | The application locale determines the default locale that will be used
    | by the translation service provider. You are free to set this value
    | to any of the locales which will be supported by the application.
    |
    */

    'locale' => 'ja',
    'faker_locale' => 'ja_JP',
..

と、faker_localeを設定してください。

テストでレコードの自動作成

ユニットテストでは、毎回のテストにおいてテストDBを空にしてモデルファクトリで新しいデータを埋めます。これを実行するために、Laravelで２つの異なるメカニズムが用意されています。

DataMigrations：Laravelのmigrationのメカニズムを使用して、毎回テストごとにDBテーブルを１から作成する
DatabaseTransactions：DBのトランザクションの機能を利用して、毎回テストごとにDBテーブルを空にする

違いは重要で、前者はテストDBにテーブルが何も存在しなくてもＯＫですが、後者では空のDBテーブルが必要です。

前者は、新規のプロジェクトで最初からLaravelのmigrationを使用してDBを管理しているならお薦めですが、既存のプログラムをLaravelに移行したプロジェクト（私の場合はこれが多い）では、違うメカニズムでDBを管理しているため前者が使用できないので後者となります。

後者では、本DBと同じDB構造とするため、以下のようにmysqldumpなどを使用してコピーする必要あります。

$ mysqludmp -u root larajapan -p -d > larajapan_test.sql
$ mysql -u root larajapan_test -p < larajapan_test.sql

ここでは、すでにmigrationの設定がなされているうえに、DatabaseMigrationsのトレイトをユニットテストの中で宣言します。

tests/Feature/LoginTest.php

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\WithoutMiddleware;
use Illuminate\Foundation\Testing\DatabaseMigrations;
//use Illuminate\Foundation\Testing\DatabaseTransactions;

use App\User;

class LoginTest extends TestCase
{
    use DatabaseMigrations;
..

ログインテスト

準備整ったところで、テストしてみましょう。まずは、ログイン成功のテスト。

先ほど設定したファクトリを使用して、最初に１つだけユーザーのレコードを作成します。その後、作成したのと同じパスワードを使用してログインを実行。実行後は、認証されていることと、ホームページにリダイレクトされることを確認します。

    /** @test */
    public function valid_user_can_login()
    {
        // ユーザーを１つ作成
        $user = factory(User::class)->create([
            'password'  => bcrypt('test1111')
        ]);

        // まだ、認証されていない
        $this->assertFalse(Auth::check());

        // ログインを実行
        $response = $this->post('login', [
            'email'    => $user->email,
            'password' => 'test1111'
        ]);

        // 認証されている
        $this->assertTrue(Auth::check());

        // ログイン後にホームページにリダイレクトされるのを確認
        $response->assertRedirect('home');
    }

次はログイン失敗のテスト。ここでもファクトリで１つだけレコードを作成しますが、わざと作成したのとは違うパスワードを使用してログインして、エラーメッセージが表示されることを確認します。

    /** @test */
    public function invalid_user_cannot_login()
    {
　　　　// ユーザーを１つ作成
        $user = factory(User::class)->create([
            'password'  => bcrypt('test1111')
        ]);

        // まだ、認証されていないことを確認
        $this->assertFalse(Auth::check());

        // 異なるパスワードでログインを実行
        $response = $this->post('login', [
            'email'    => $user->email,
            'password' => 'test2222'
        ]);

        // 認証失敗で、認証されていないことを確認
        $this->assertFalse(Auth::check());

        // セッションにエラーを含むことを確認
        $response->assertSessionHasErrors(['email']);

        // エラメッセージを確認
        $this->assertEquals('メールアドレスあるいはパスワードが一致しません',
            session('errors')->first('email'));

$responseに使用されるassertの関数は、phpunitからのassertTrueと違い、Laravelで宣言されているものです。

参照としては、本サイトの以下

https://laravel.com/docs/5.4/http-tests#available-assertions

ですが、そこには掲載されていない関数もあるので、以下もチェックしてください。

https://laravel.com/api/5.4/Illuminate/Foundation/Testing/TestResponse.html

最後に、テストを実行してみましょう。

$ vendor/bin/phpunit --filter LoginTest
PHPUnit 5.7.22 by Sebastian Bergmann and contributors.

....                                                                4 / 4 (100%)

Time: 1.09 seconds, Memory: 16.00MB

OK (4 tests, 12 assertions)

エラーもなく成功ですね！

今回のコードは以下から利用可能です。

https://github.com/lotsofbytes/larajapan/blob/5.4-test/tests/Feature/LoginTest.php

ユーザー認証のテスト(1) Laravel 5.4

Wed, 31 Jan 2018 13:54:46 +0900

Laravelでのユーザー認証は私のブログの中では最も人気のあるトピックです。今回は、私のLaravelの日本語のレポジトリ（Laravel 5.4）のコードをもとに、ユーザー認証のテストに取り組んでいきます。

テストの種類

テストと言っても、いくつか種類があり、Laravel5.4からはtestsのディレクトリ構造も変わり、

tests
├── CreatesApplication.php
├── Feature
│   └── ExampleTest.php
├── TestCase.php
└── Unit
    └── ExampleTest.php

のようにFeatureとUnitの２つのサブディレクトリができました。

Unitには、一般的にはユニットテストと呼ばれるもので、大方は画面の表示を伴わないModelのメソッドに対するテストを作成します。一方、Featureには、機能テストやアクセプタンステストとも言われ、複数のクラスの複数のメソッドが関わる主にコントローラの機能を検証するためで、あたかもユーザーがテストするようなテストを作成します。

私の今までの開発では、比較的作成しやすいUnitテストが主で、Featureテストは皆無に近く、人間のテスターがその仕事を行っています。人間をFeatureテストに置き換える予定はないですが、Laravelが提供するテストの環境がFeatureテストを作成しやすくなってきているので、この機会に習得しようということです。

Laravel5.4では、Featureテストのために、２つのテストのフレームワークが提供されています。

HTTPテスト：ブラウザを通さないエンドポイントのテスト
ブラウザテスト(Dusk)：ブラウザキットを利用したテスト

ここでは、まず、追加のパッケージのインストールも要らない、高速なHTTPテストを作成していきます。

準備

github.comにおいて以下のブランチを用意したので利用してください。

https://github.com/lotsofbytes/larajapan/tree/5.4-test

インストールは以下を参照してください。

Laravelの日本語のレポジトリ（Laravel 5.4）

設定したら、必ず以下を実行してブランチを変えてください。

$ git checkout l54-test

また、そこでは、phpunit.xmlを編集も必要です。以下を参考にしてください。

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="bootstrap/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Feature">
            <directory suffix="Test.php">./tests/Feature</directory>
        </testsuite>

        <testsuite name="Unit">
            <directory suffix="Test.php">./tests/Unit</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist processUncoveredFilesFromWhitelist="true">
            <directory suffix=".php">./app</directory>
        </whitelist>
    </filter>
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="APP_URL" value="http://localhost"/>
        <env name="CACHE_DRIVER" value="array"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="DB_HOST" value="localhost"/>
        <env name="DB_DATABASE" value="larajapan_test"/>
        <env name="DB_USERNAME" value="test"/>
        <env name="DB_PASSWORD" value="password"/>
        <env name="MAIL_DRIVER" value="log" />
        <env name="QUEUE_DRIVER" value="sync"/>
    </php>
</phpunit>

テストのDBは.envで設定しているものと違うDBが必要なことに注意してください。

最初のテスト

もとからあるtests/Feature/ExampleTest.phpのファイルを、LoginTest.phpと改名して以下のように編集します。

namespace Tests\Feature;

use Tests\TestCase;
use Illuminate\Foundation\Testing\WithoutMiddleware;
use Illuminate\Foundation\Testing\DatabaseMigrations;
use Illuminate\Foundation\Testing\DatabaseTransactions;

class LoginTest extends TestCase
{
    /** @test */
    public function user_can_view_login()
    {
        $response = $this->get('login');

        $response->assertStatus(200);
    }

    /** @test */
    public function unauthenticated_user_cannot_view_home()
    {
        $this->get('home')
        	->assertRedirect('login');
    }
}

最初のテストuser_can_view_loginは、ログイン画面が閲覧できるかどうかのテストです。返ってくるHTTPのステータスのコードが200なら、成功ということです。これが404（ページが見つかりません）とかだと何かがおかしいということになります。

次のテストunauthenticated_user_cannot_view_homeは、認証が必要なホームページに、認証もなしにアクセスしてみます。もちろん、アクセスできないでログイン画面にリダイレクトされるはずです。

ここ、メソッドが連結されていることに気づきましたか？

最初のテストの例のように、以下のよう2つの文に分けても書くこともできます。

$response = $this->get('home');
$response->assertRedirect('login');

これらのテストの実行ですが、Laravelのインストールにより、すでにvendorのディレクトリにphpunitのパッケージもインストールされています。

ということで、

$ vendor/bin/phpunit
PHPUnit 5.7.23 by Sebastian Bergmann and contributors.

...                                                                 3 / 3 (100%)
Time: 171 ms, Memory: 10.00MB

OK (3 tests, 4 assertions)

と実行してテストは皆成功となります。3 testsとあるのは、app/tests/Unit/ExampleTestがあるからです。以下のようにフィルタを書ければ、LoginTestの中のテストだけや、user_can_view_loginの1つテストだけの実行も可能です。

$ vendor/bin/phpunit --filter=LoginTest
HPUnit 5.7.23 by Sebastian Bergmann and contributors.

..                                                                  2 / 2 (100%)

Time: 157 ms, Memory: 10.00MB

OK (2 tests, 3 assertions)

$ vendor/bin/phpunit --filter=user_can_view_login
PHPUnit 5.7.23 by Sebastian Bergmann and contributors.

.                                                                   1 / 1 (100%)

Time: 111 ms, Memory: 10.00MB

OK (1 test, 1 assertion)

会員編集フォーム

Sat, 05 Mar 2016 07:36:54 +0900

ウェブのプログラミングでなんといっても難しいのはフォーム画面のプログラムです。テキスト入力、ドロップダウン、ファイルのアップロード機能、さらにjqueryやangularなどのフロントエンドのjavascriptも入れば、無限の可能性があります。

以前紹介したLaravelの付録の会員認証サンプルの会員登録画面は、php artisan make:authコマンドで自動作成されますが、ログイン後に会員がEメールアドレスや名前を編集する画面は作成されません。

今回はこの編集画面を作成してみます。

まず、新規のコントローラ作成します。

php artisan make:controller User/UserController

を実行して、それを以下のように編集し、

UserController.php

namespace App\Http\Controllers\User;

use Illuminate\Http\Request;

use App\Http\Requests;
use App\Http\Controllers\Controller;
use App\User;

use Auth;
use Validator;

class UserController extends Controller
{
    protected $user;

    public function __construct()
    {
        $this->middleware('auth:user'); // 認証

        $this->user = Auth::guard('user')->user();
    }

    public function getProfile()
    {
        return view('user/profile')->with(['user' => $this->user]);
    }

    public function postProfile(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'name'  => 'required|max:255',
            'email' => 'required|email|max:255|unique:users,email,'.$this->user->id
        ]);

　　　　//　エラーチェック
        if ($validator->fails())
        {
            return back()->withInput()->withErrors($validator);
        }

　　　　// データを更新
        $this->user->update([
            'name'  => $request->input('name'),
            'email' => $request->input('email')
        ]);

        return redirect('user/home');
    }
}

Validationでは、emailのチェックは、$this->user->idを除くusersのレコードを対象に他に同じEメールが使われていないかチェックします。

次に、以下のようなテンプレートを作成します。

profile.blade.php

@extends('user.layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-heading">Profile</div>
                <div class="panel-body">
                    <form class="form-horizontal" role="form" method="POST" action="{{ url('/user/profile') }}">
                        {!! csrf_field() !!}

                        <div class="form-group{{ $errors->has('name') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">名前</label>

                            <div class="col-md-6">
                                <input type="text" class="form-control" name="name" value="{{ old('name', $user->name) }}">

                                @if ($errors->has('name'))
                                    <span class="help-block">
                                        <strong>{{ $errors->first('name') }}</strong>
                                    </span>
                                @endif
                            </div>
                        </div>

                        <div class="form-group{{ $errors->has('email') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">Eメール</label>

                            <div class="col-md-6">
                                <input type="email" class="form-control" name="email" value="{{ old('email', $user->email) }}">

                                @if ($errors->has('email'))
                                    <span class="help-block">
                                        <strong>{{ $errors->first('email') }}</strong>
                                    </span>
                                @endif
                            </div>
                        </div>

                        <div class="form-group">
                            <div class="col-md-6 col-md-offset-4">
                                <button type="submit" class="btn btn-primary">
                                    保存
                                </button>
                            </div>
                        </div>
                    </form>
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

ここ、old()のLaravelの関数が使用されていますが、すでに存在する値を編集するので、デフォルトとしてDBからの値が入っていることに注意してください。

 <input type="text" class="form-control" name="name" value="{{ old('name', $user->name) }}">

コントローラでは、validationエラーが発生して、現在の画面に戻る必要があります。そのときは、withInput()がセッションに入力の値を保存して、back()で現在の画面にリダイレクトします。リダイレクト後には、old()は、デフォルトでなくセッションに保存された入力された値を表示します。

最後に、routes.phpを以下のように編集します。

routes.php

Route::group(['prefix' => 'user', 'middleware' => 'web'], function () {
...
    Route::get('profile', 'User\UserController@getProfile');
    Route::post('profile', 'User\UserController@postProfile');
});

以下のように、認証のミドルウェアをコントローラから移してもOKです。

routes.php

Route::group(['prefix' => 'user', 'middleware' => 'web'], function () {
...
   Route::group(['middleware' => 'auth:user' ], function () {
        Route::get('home', 'User\HomeController@index');
        Route::get('profile', 'User\UserController@getProfile');
        Route::post('profile', 'User\UserController@postProfile');
    });
});

ユーザー認証（７）スロットルのユニットテスト

Sun, 20 Dec 2015 07:30:44 +0900

前回話したログインのスロットル機能。もちろん手動、つまりブラウザ、で確認はできます。しかし、手動ではいちいち面倒ですね。自動で動作を確認できたらもっと良いです。そこで登場するのがユニットテスト。難しくはないです。チェックしたいのは、

パスワードが正しいときのログインが成功するかのテスト
パスワードを間違えて、失敗回数がデフォルトの５回となったときに、スロットされるかのテスト
その後デフォルトの６０秒待って、パスワードが正しいときに成功するかのテスト

他にもいくつか考えられますが、最低限は以上としてテストを作成してみましょう。

注意：パスワードには理解しやすいように日本語としていますが、実際は英数字が一般的です。

class LoginTest extends TestCase
{
    public function testLoginSuccess()
    {
        $this->visit('/auth/login')
            ->type('test@gmail.com', 'email')
            ->type('正しいパスワード', 'password')
            ->press('保存')
            ->see('ホームページ');
    }

    public function testLoginThrottle()
    {
        for($i=1;$i <=5; $i++)
        {
            $this->visit('/auth/login')
                ->type('test@gmail.com', 'email')
                ->type('間違ったパスワード', 'password')
                ->press('ログイン')
                ->see('Eメールとパスワードにマッチするレコードがありません。');
        }

        $this->visit('/auth/login')
            ->type('test@gmail.com', 'email')
            ->type('間違ったパスワード', 'password')
            ->press('ログイン')
            ->see('ログインの失敗回数が設定を超えました。次回のログインまで６０秒お待ちください。');

        sleep(10);

        $this->visit('/auth/login')
            ->type('test@gmail.com', 'email')
            ->type('正しいパスワード', 'password')
            ->press('ログイン')
            ->see('ログインの失敗回数が設定を超えました。');

        sleep(50);

        $this->visit('/auth/login')
            ->type('test@gmail.com', 'email')
            ->type('正しいパスワード', 'password')
            ->press('ログイン')
            ->see('ホームページ');
    }
}

最初のテスト、testLoginSuccessは、正しいパスワードを入力したときのテストで、その後「ホームページ」という文が入ったページへ行くとする仮定。

次のtestLoginThrottleは、スロットルされるまでの失敗回数の確認とスロットル解除の確認のテスト。まず間違ったパスワードを入れて５回失敗させます。画面には、「Eメールとパスワードにマッチするレコードがありません」のエラーメッセージが表示されます。その後、さらに失敗すると、今度はログインをスロットルしたメッセージが表示されます。ここから６０秒経過しないと次のログインができません。確認のために１０秒後に正しいパスワードでログインしてみましょう。そこでは、さらに「ログインの失敗回数が設定を超えました。」を含むエラーメッセージがでます。残りの秒数は誤差が出ると思うので、その部分の確認はしません。そして、５０秒後（つまり、スロットル開始から６０秒後）には、正しいパスワードでログインが成功となるはずです。

さて、ここで注意です。Laravelに含まれるphpunitのテストの設定ファイルは、以下の内容です。

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="bootstrap/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Application Test Suite">
            <directory>./tests/</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist>
            <directory suffix=".php">app/</directory>
        </whitelist>
    </filter>
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="CACHE_DRIVER" value="array"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="QUEUE_DRIVER" value="sync"/>
    </php>
</phpunit>

前回話したように、ログイン失敗回数や現在スロットルされていることなどの情報は、デフォルトではファイルを使用して行っています。しかし、テストでは CACHE_DRIVERは配列設定となっています。私のテストでは、そのためか上のテストはスロットル期間終了後に成功とはなりませんでした。どうも残りの秒数のカウントが負となっていしまい、うまくいかない。

この設定をphpunit.xmlでarrayからfileあるいはdatabaseに変更とすると、うまく行きました。

入力の空白文字をトリム（２）全角スペース

Sat, 24 Oct 2015 09:50:38 +0900

前回の「空白文字の入力をトリムする」の続きです。

まず、動作確認を簡単にするために、ユニットテストを作成しましょう。

入力画面のユニットテストをもとに、いろいろなデータをテストできるように、データプロバイダーを使用します。

use Illuminate\Foundation\Testing\WithoutMiddleware;
use Illuminate\Foundation\Testing\DatabaseMigrations;
use Illuminate\Foundation\Testing\DatabaseTransactions;

class SignupTest extends TestCase
{
    use DatabaseTransactions;

    /**
     * @dataProvider providerTrimpInput
     */
    public function testTrimpInput($last_name, $expected)
    {
        $this->visit('/signup')
            ->type('success@gmail.com', 'email')
            ->type('testtest', 'password')
            ->type('testtest', 'password_confirmation')
            ->type($last_name, 'last_name')
            ->type('太郎', 'first_name')
            ->press('保存')
            ->see('会員登録完了');

        $member = \App\Member::where('email', 'success@gmail.com')->first();

        $this->assertEquals($expected, $member->last_name);
    }

    public function providerTrimpInput()
    {
        return [
            [ '山田', '山田'],
            [ ' 山田 ', '山田'],   //半角スペース
            [ '　山田　', '山田'], //全角スペース
        ];
    }
}

ユニットテストのデータプロバイダーは、テストとデータを分けることにより、１つのテストでいろいろなデータのテストが可能となります。必要なのは、コメントのphpDocの@dataProviderでデータを供給する関数名を指定することと、そのデータ供給の関数を作成することです。この例では３つのデータを用意することにより、３回テストが実行されます。

テスト実行結果は、以下です。

PHPUnit 4.8.9 by Sebastian Bergmann and contributors.

..F

Time: 360 ms, Memory: 26.50Mb

There was 1 failure:

1) SignupTest::testTrimpInput with data set #2 ('　山田　', '山田')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'山田'
+'　山田　'

/vol1/usr/www/shop/webdocs/demo/tests/SignupTest.php:27

FAILURES!
Tests: 3, Assertions: 12, Failures: 1.

２番目の半角のスペースのデータはトリムされ成功となり、３番目の全角スペースが前後にあるデータでは失敗となります。

さて、全角スペースはどう対応しましょうか？

再度、trim関数の仕様を見てみましょう。

 string trim ( string $str [, string $character_mask = " \t\n\r\0\x0B" ] )

この関数は str の最初および最後から空白文字を取り除き、 取り除かれた文字列を返します。
2番目のパラメータを指定しない場合、 trim()は以下の文字を削除します。

    " " (ASCII 32 (0x20)), 通常の空白。
    "\t" (ASCII 9 (0x09)), タブ。
    "\n" (ASCII 10 (0x0A)), リターン。
    "\r" (ASCII 13 (0x0D)), 改行。
    "\0" (ASCII 0 (0x00)), NULバイト
    "\x0B" (ASCII 11 (0x0B)), 垂直タブ

そう、２番目のパラメータに全角スペースを入れてあげればよいですね。

trim($val, ' \t\n\r\0\x0B　');//全角スペースは最後の空白文字

しかし、これはテストしたところうまくいきませんでした。全角のスペースが入る値には対応するようですが、半角の文字列では文字列によっては空白文字でないものもトリムしてしまいます。trimの関数はユニコード対応でないようですね。それならば、mb_trimと思いますが、残念ながらこれが存在しません。

いろいろ調べたところ、preg_replaceが使えそうです。

パターンは、

’/(^\s+)|(\s+$)/u’

\sは空白文字のエスケープシーケンスであり、ドキュメントでは以下の記述があります。

エスケープシーケンス

空白文字とは HT (9)、LF (10)、FF (12)、CR (13)、スペース (32) のことです。しかし、ロケールを指定したマッチングを行った場合には、128から255までのコードポイントの文字 (たとえば NBSP (A0)) も空白文字とみなされる可能性があります。

ということで、trimで削除する空白文字とともにユニコードの全角スペースも削除してくれます。

ミドルウェアを書き直すと、

app/Http/Middleware/TrimInput.php

namespace App\Http\Middleware; 

use Closure; class TrimInput {

    /** 
     * Handle an incoming request. 
     * 
     * @param \Illuminate\Http\Request $request 
     * @param \Closure $next 
     * @return mixed 
     */ 
    public function handle($request, Closure $next) { 

        $input = $request->all();

        $trimmed = [];

        foreach($input as $key => $val)
        {
            $trimmed[$key] = preg_replace('/(^\s+)|(\s+$)/u', '', $value);
        }

        $request->merge($trimmed);

        return $next($request);
    }
}

先のユニットテストの結果は？

PHPUnit 4.8.9 by Sebastian Bergmann and contributors.

...

Time: 359 ms, Memory: 26.50Mb

OK (3 tests, 12 assertions)

成功です！

次回は、配列の入力値の個々の値の空白文字のトリムの対応です。

入力画面のユニットテスト

Mon, 21 Sep 2015 03:18:35 +0900

ユニットテスト（PHPの場合は、phpunit）を使い始めて、２，３年。その重要さは理解しているものの、つい最近まで、コードの大変さによりなかなか多用はしていませんでした。

データベース絡みや入力画面絡みのテスト、書くのはやっかいです。しかし、ウェブのアプリの開発には、データベースや入力画面があって当然。ここのテストを自動化をせずにいったいどこでする？とも思う。

しかし、どうしてやっかいなのでしょう、これら？

例えば、前回の会員登録の件では、テストとして考えられるのは、

まずは、エラーを出して確認するテストたち：

必須の項目に値がないときにエラーとなるか。
EメールにEメールでないものを入力したときにエラーとなるか。
すでに登録した会員のEメールを入れたときにエラーとなるか（重複チェック）。

そして、エラーがなく、会員登録成功したときの確認のテストも必要です。

前者のエラーを出して確認するテストは、コントローラーでなくモデルに入れてテストが可能かもしれません。ララベルのバリデーションはすでに一貫しているし、カスタマイズのバリデーションも同様にテスト可能です。

しかし、それらユニットテストは個々のバリデーションをテストするだけで、それら集合した入力画面に対してのファンクショナルテストやアクセプタンステストは難しいです。あたかもユーザーが入力するようなテストです。

さらに、後者のエラーが出ない成功の確認のテストは、実際にDBにレコードが作成されてしまいます。つまり１回成功テストすると、次回は重複でエラーとなり成功のテストができなくなります。もちろん、毎回レコードを削除するという手段もありますが（これはDBテストとして将来に紹介します）、違うDBを用意するとかお膳立てがかなり面倒です。

もちろん、ここで、ララベルがそのフレームワークを活かしたユニットテストの登場です（注意：ララベル5.1での前提です）。

まずは、Eメールアドレスの重複による失敗のテストです。

class SignupTest extends TestCase
{
    public function testSignupFail()
    {
        $this->visit('/signup')
            ->type('dup@gmail.com', 'email')
            ->type('testtest', 'password')
            ->type('testtest', 'password_confirmation')
            ->type('山田', 'last_name')
            ->type('太郎', 'first_name')
            ->press('保存')
            ->dontSee('会員登録完了');
    }
}

このテストは、ユーザーが以下のような画面を経験したと同じ状況をテストします。すでにDBにdup@gmail.comが存在していると仮定です。

16行目の “dontSee(‘会員登録完了’);” では、エラーになるために成功時の「会員登録完了」の文字が画面には見えないよ、つまりdon’t seeということです。

今度は、成功時のテストですが、

use IlluminateFoundationTestingWithoutMiddleware;
use IlluminateFoundationTestingDatabaseMigrations;
use IlluminateFoundationTestingDatabaseTransactions;

class SignupTest extends TestCase
{
    use DatabaseTransactions;

    public function testSignupSuccess()
    {
        $this->visit('/signup')
            ->type('success@gmail.com', 'email')
            ->type('testtest', 'password')
            ->type('testtest', 'password_confirmation')
            ->type('山田', 'last_name')
            ->type('太郎', 'first_name')
            ->press('保存')
            ->see('会員登録完了');
    }
}

先の失敗の例と違って、今度はdon’t seeでなくsee(‘会員登録完了’)となっています。

しかし会員登録完了なのにDBのレコードは作成されません。そう、７行目のuse DatabaseTransactionsの宣言により、レコードの作成を試みるもののDBのトランザクション機能を使用してわざと変更をロールバックさせています。これにより作成あるいは変更されたデータを手動で戻さずに、何回でもテストの実行が可能となるわけです。もちろん、トランザクション機能があるDB、mysqlならinnodbの使用でないとできないことです。

先の２つテストを合わせて、実行すると、「OK」という結果です。

$ phpunit tests/SignupTest
PHPUnit 4.8.2 by Sebastian Bergmann and contributors.

..

Time: 313 ms, Memory: 27.25Mb

OK (2 tests, 7 assertions)

ユニットテスト 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を設定

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

Laravel FormRequestのユニットテスト（２）

テスト対象

prepareForValidation()を含めたテスト

FormRequest全体をテストしながら、ルートパラメータも取得したい場合

包括的なテストとメソッド単体のテストまとめ

Laravel FormRequestのユニットテスト（１）

テスト対象

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

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

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

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