テスト on ララジャパン

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

Sun, 27 Jul 2025 01:52:33 +0900

このところ、AIの進化によりテストツールとしてのPlaywrightが便利だという話を目にする機会が多くなってきました。実際、2025年現在GoogleトレンドでもCypressやSeleniumの検索数を上回るなど、Playwrightへの注目度が高くなっているようです。以前に当ブログでCypressについてご紹介しましたが、Playwrightも気になったので少し触ってみました。

Playwrightとは

Playwrightとは、Microsoftが開発したE2E（End-to-End）テスト自動化ツールです。Webアプリケーションの動作を実際のブラウザで自動テストでき、Chrome、Firefox、Safari（WebKit）の3つのブラウザエンジンに対応しています。

ユーザーの操作を記録してテストコードを自動生成するcodegen機能や、GitHub Actionsとの連携によるコード変更時やデプロイ時の自動テスト実行も可能で、モダンなWeb開発ワークフローに適したツールとなっています。

インストール環境

Laravelで構築されたアプリケーションのE2EテストとしてPlaywrightを導入します。Laravelアプリとは異なるディレクトリにPlaywrightをインストールすることも可能ですが、今回はプロジェクトルートにインストールします。

Laravelのテストディレクトリとしてすでにtests/が存在するため、Playwright用ディレクトリはe2e/として以下の構成となるようインストールしてゆきます。

laravel-app/
├── app/
├── config/
├── database/
├── public/
├── resources/
├── routes/
├── tests/          # PHPUnit用のテスト
├── e2e/            # Playwright用のE2Eテスト ← ここ
├── package.json
└── composer.json

Playwrightインストール

まずはインストールです。最新版のインストールにはnode.jsのバージョン20、22もしくは24が必要です。

公式の手順にそって、プロジェクトのルートディレクトリで以下のコマンドを実行します。

$ npm init playwright@latest

いくつか質問されますので、プロジェクトに合う形で指定してゆきます。

.....
Do you want to use TypeScript or JavaScript? · TypeScript
Where to put your end-to-end tests? · e2e
Add a GitHub Actions workflow? (y/N) · false
Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) › true
.....

TypeScriptかJavaScriptか？では、今回はTypescriptを選択しました。また、Playwright用のテストケースを置くディレクトリはe2eに。

GitHub Actions workflowについては、初回は設定をシンプルに保ちたいのでfalseとしました。最後の「Install Playwright browsers」の質問では、Playwright専用のブラウザ（Chromium、Firefox、WebKit）を自動でダウンロードするかを選択できます。今回はtrueを選択して自動インストールしました。

インストールが完了すると、新しく以下のファイルが作成されます。

And check out the following files:
  - ./e2e/example.spec.ts - Example end-to-end test
  - ./tests-examples/demo-todo-app.spec.ts - Demo Todo App end-to-end tests
  - ./playwright.config.ts - Playwright Test configuration

/e2e/example.spec.tsは、テストの動作を確認するためのシンプルなサンプルテスト用のファイルです。 ./tests-examples/demo-todo-app.spec.tsも同じくサンプルテストですが、Playwrightが提供する実際のTodoアプリケーションを対象とした、より実践的なデモ用のE2Eテストが書かれたファイルとなっているようです。そして設定用のplaywright.config.tsが、ルートディレクトリにインストールされています。

Playwright設定ファイル

Playwrightの動作確認をする前に、playwright.config.tsの中を少し見てみます。

/playwright.config.ts

.....
export default defineConfig({
  testDir: './e2e',
  /* Run tests in files in parallel */
  fullyParallel: true,
  /* Fail the build on CI if you accidentally left test.only in the source code. */
  forbidOnly: !!process.env.CI,
  /* Retry on CI only */
  retries: process.env.CI ? 2 : 0,
  /* Opt out of parallel tests on CI. */
  workers: process.env.CI ? 1 : undefined,
  /* Reporter to use. See https://playwright.dev/docs/test-reporters */
  reporter: 'html',
  /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
  use: {
    /* Base URL to use in actions like `await page.goto('/')`. */
    // baseURL: 'http://localhost:3000',

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

インストール時に指定した通り、テストファイルの置き場所はtestDir: ‘./e2e’と設定されています。今のe2eディレクトリにはexample.spec.tsだけが入っており、新しいテストファイルはここに追加してゆく形ですね。

また初期設定ではコメントアウトとなっていますが、テスト内で相対パスを使う際のベースとなるbaseURLも項目として記載されています。

それ以外の主な設定として、以下のような項目が挙げられています。

fullyParallel：テストの並列実行
retries：テスト失敗時のリトライ設定
workers：並列実行のプロセス数
reporter：レポートの生成

サンプルテストを実行

では早速、サンプルテストを実行してみます。e2eディレクトリに存在するすべてのspec.tsファイルを対象にテストを実行する場合、以下のコマンドを使います。

%  npx playwright test

ファイルを指定して実行する場合は以下のいずれかで可能です。

$ npx playwright test example.spec.ts
$ npx playwright test example

コマンドを実行すると、ターミナルに以下が出力されました。

Running 6 tests using 4 workers
  6 passed (11.4s)

To open last HTML report run:

  npx playwright show-report

ヘッドレスモードでテストが実行されたようで、ブラウザも何も起動せずあっという間にテストが完了しました。ターミナルに出力されたメッセージに従って、以下のコマンドを実行します。

$ npx playwright show-report

localhost:9323でHTMLレポートが表示されました。Chrome、Firefox、Safari（webkit）でテストが実行されていますね。このレポートは、Macの場合 Ctrl+C で閉じることができます。

テストが問題なく実行されたことはわかりましたが、ブラウザが何も立ち上がらないのは少し心配ですので今度はオプションをつけて実行します。

$ npx playwright test --headed

–headedをつけて実行すると、一瞬ブラウザが立ち上がりましたがあっという間に閉じてテストが完了しました。サンプルテストなので早いというのはあるかもしれませんが、ブラウザの起動からテストが始まるまでがかなり早いように感じます。

また、テストを手動で１つづつ動かしながらブラウザでの動作も確認したいという場合は、–uiをつけて実行します。

$ npx playwright test --ui

PlaywrightのWebUIが立ち上がり、実行するテストファイル・テスト名などを選択して実行することができます。テストコードも下部に表示されるので、作成したテストコードの動作を確認しながら動かしたりエラー時のデバッグなどに使うと良さそうですね。

テスト失敗時

今度は失敗した場合の動作を確認します。example.spec.tsを一部編集して、エラーが起こるようにします。以下のtoHaveTitle(/Playwright/)の箇所で「アクセスしたページのタイトルに"Playwright"という文字列が含まれているか」をアサーションしていますので、“Plaaywright"とaを重複するよう書き換えてみます。

/e2e/example.spec.ts

.....
test('has title', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // Expect a title "to contain" a substring.
  await expect(page).toHaveTitle(/Plaaywright/); // aを重複するように編集
});
.....

これでテストを実行してみると、ターミナルへ以下のようなエラーメッセージ出力に加え、レポートが自動で立ち上がりました。

$ npx playwright test

Running 6 tests using 4 workers
  1) [chromium] › e2e/example.spec.ts:3:1 › has title ──────────────────────────────────────────────

    Error: Timed out 5000ms waiting for expect(page).toHaveTitle(expected)

    Locator: locator(':root')
    Expected pattern: /Plaaywright/
    Received string:  "Fast and reliable end-to-end testing for modern web apps | Playwright"
    Call log:
      - Expect "toHaveTitle" with timeout 5000ms
      - waiting for locator(':root')
        9 × locator resolved to <html lang="en" dir="ltr" data-theme="light" data-has-hydrated="true" data-theme-choice="system" class="plugin-pages plugin-id-default" data-rh="lang,dir,class,data-has-hydrated">…</html>
          - unexpected value "Fast and reliable end-to-end testing for modern web apps | Playwright"


       5 |
       6 |   // Expect a title "to contain" a substring.
    >  7 |   await expect(page).toHaveTitle(/Plaaywright/);
         |                      ^
       8 | });
       9 |
      10 | test('get started link', async ({ page }) => {
        at /Users/hiro/MySite/diary/e2e/example.spec.ts:7:22

    Error Context: test-results/example-has-title-chromium/error-context.md

  2) [firefox] › e2e/example.spec.ts:3:1 › has title 
.....

次回は、Playwrightの基本的なテストコードの書き方をご紹介します。

既存のＤＢからmigrationファイルを自動作成

Fri, 10 Jan 2020 03:33:08 +0900

私が現在管理するプロジェクトのほとんどは、Laravelのフレームワーク採用以前から存在したphpのプロジェクトです。嬉しいことにお客様から移行の機会を与えられて、ほとんどLaravelに書き換えることができました。しかし、それらのプロジェクトのDBの管理には、Laravelのmigrationを使用していません。私が開発したオンラインのツールが生成するSQLファイルでDBの変更を行っています。最近になって、プロジェクトのデータベーステストを行う必要が出て、migrationのファイルを用意しなければなくなりました。

どうして、migrationのファイルが必要？

今までは、dbunitなるものを使用してデータベーステストを行っていましたが、これが去年に作者（phpunitの作者でもある）の意向で開発が停止となりました。それゆえに、テストにおいてLaravelのRefreshDatabaseトレイトの使用に変えていくことが突然に必要になったわけです。

RefreshDatabaseは、毎回のテストの実行において、

$ php artisan migrate:fresh

の実行と同様に、migrationファイルで定義されたDBのテーブルをすべて削除し、再度一からそれらを作成します。つまり、データベースのテーブルをすべてゼロレコードの状態としてくれます。それゆえに、既存のDBのすべてのテーブルのmigrationを作成する必要があるのです。

migrationファイル自動生成ツール

既存のDBからmigrationファイルを作成するツールはないかと、探した結果、以下のツールが出てきました。

https://github.com/Xethron/migrations-generator

ツールのインストールには、

$ composer require --dev "xethron/migrations-generator"

をコマンドラインで実行します。

migrationファイルを作成するには、artisanの実行となります。laravel 5.8で新規のプロジェクトを作成して実行してみました。

$ php artisan migrate:generate
Using connection: mysql

Generating migrations for: password_resets, users

 Do you want to log these migrations in the migrations table? [Y/n] :
 > y

 Next Batch Number is: 2. We recommend using Batch Number 0 so that it becomes the "first" migration [Default: 0] :
 > 2

Setting up Tables and Index Migrations
Created: /vol1/usr/www/repos/repos/l58-new/database/migrations/2020_01_08_191742_create_password_resets_table.php
Created: /vol1/usr/www/repos/repos/l58-new/database/migrations/2020_01_08_191742_create_users_table.php

Setting up Foreign Key Migrations


Finished!

上の実行においては、２つ質問が尋ねられます。

最初は、migrationsのDBテーブルにログを作成するか？ 2番目は、そのログにおいてのバッチ番号をなんとするか？

上では、yと2と答えたところ、migrationsのデータは以下のようになりました。

mysql> select * from migrations;
+----+------------------------------------------------+-------+
| id | migration                                      | batch |
+----+------------------------------------------------+-------+
|  1 | 2014_10_12_000000_create_users_table           |     1 |
|  2 | 2014_10_12_100000_create_password_resets_table |     1 |
|  3 | 2020_01_08_191742_create_password_resets_table |     2 |
|  4 | 2020_01_08_191742_create_users_table           |     2 |
+----+------------------------------------------------+-------+
4 rows in set (0.00 sec)

すでに、php artisan migrateが実行されていたので、最初の２つのレコードはそのときに生成されていたものです。これらはLaraelのデフォルトのmigrationファイルです。

一方、generateで生成されたのは次の２つのレコードですが、見ての通り既存のものと重複となってしまいました。既存のDBをもとに１からDBテーブルを作成するという目的では、generate実行の前にmigrationsテーブルを空としたほうが良さそうですね。

さて、生成されたものと、デフォルトのmigrationファイルを比べてみましょう。

デフォルト：2014_10_12_000000_create_users_table.php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->string('email')->unique();
            $table->timestamp('email_verified_at')->nullable();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('users');
    }
}

生成：2020_01_08_191742_create_users_table

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;

class CreateUsersTable extends Migration {

	/**
	 * Run the migrations.
	 *
	 * @return void
	 */
	public function up()
	{
		Schema::create('users', function(Blueprint $table)
		{
			$table->bigInteger('id', true)->unsigned();
			$table->string('name');
			$table->string('email')->unique();
			$table->dateTime('email_verified_at')->nullable();
			$table->string('password');
			$table->string('remember_token', 100)->nullable();
			$table->timestamps();
		});
	}


	/**
	 * Reverse the migrations.
	 *
	 * @return void
	 */
	public function down()
	{
		Schema::drop('users');
	}

}

やや違いがありますね。例えば、email_verified_atの定義、なぜかtimestampからdateTimeとなっています。また、bigIncrementやrememberTokenに対応するフィールドも生成では変わっています。しかし、これらは、実行されるDBテーブルでは同じとなります。

ということで、mysqldumpの結果と見比べて、手動での調整が必要となりそうです。しかし、かなりの部分を作成してくれるので十分使えそうです。