Playwrightの新機能 使ってみた【ジェネレータエージェントについて】
はじめに
前回の記事(Playwrightの新機能 使ってみた【プランナーエージェントについて】)では、Playwright 1.56の新機能「Test Agents」のプランナーエージェントを使って、Playwright公式サイトのテストプランを自動生成しました。
今回はその続編として、ジェネレーターエージェント(🎭 Generator) を使って、生成したテストプランから実行可能なPlaywrightテストコードを自動生成してみます。
前回のおさらい
前回、プランナーエージェントで生成したテストプラン:
specs/
├── playwright-website-navigation.md # 英語版(613行、45+シナリオ)
└── 検索機能テストプラン.md # 日本語版(556行、35シナリオ)
これらのMarkdownファイルには、人間が読める形式でテストシナリオが記述されています。
テストプランの例(抜粋):
#### 4.1 基本的な検索クエリの実行
**手順:**
1. Playwright公式サイトにアクセス
2. 検索モーダルを開く
3. 検索フィールドに「browser」と入力
**期待される結果:**
- 入力中にリアルタイムで検索結果が表示される
- 検索結果がカテゴリ別に分類されて表示される
- 各検索結果に検索キーワードがハイライト表示される
...
ジェネレーターエージェントとは?
ジェネレーターエージェントは、Markdownで書かれたテストプランを読み取り、実行可能なPlaywrightテストコード(JavaScript/TypeScript)を自動生成します。
ジェネレーターエージェントの特徴
- ✅ Markdownテストプランから実行可能なコードを生成
- ✅ 適切なロケーターとアサーションを自動選択
- ✅ Playwrightベストプラクティスに準拠
- ✅ 実際にブラウザを動かしながら検証
ジェネレーターエージェントの実行
前提条件
前回のプランナーエージェントで生成したファイルが存在する状態からスタートします。
try-playwright-agent/
├── package.json
├── playwright.config.js
├── tests/
│ └── seed.spec.js # シードテスト
└── specs/
└── 検索機能テストプラン.md # プランナーが生成したテストプラン
ジェネレーターエージェントの起動
Claude Code(またはAIツール)でジェネレーターエージェントを起動します。
実行したプロンプト:
Use the test plan from specs/検索機能テストプラン.md to generate executable Playwright tests in JavaScript.
Focus on generating tests for the following scenarios from the test plan:
1. 検索ボタンの表示確認 (Verify search button presence)
2. クリックで検索モーダルを開く (Open search modal via click)
3. Command+Kで検索モーダルを開く (Open search modal via Command+K)
4. 基本的な検索クエリの実行 (Execute basic search query)
Please generate these tests as JavaScript files in the tests/ directory. Use the seed file tests/seed.spec.js as a reference for the project setup.
Make sure the tests are:
- Written in JavaScript (not TypeScript)
- Use proper locators and assertions
- Include appropriate waits and verifications
- Follow Playwright best practices
(日本語版)
specs/検索機能テストプラン.md のテストプランを使用して、実行可能なPlaywrightテストをJavaScriptで生成してください。
テストプランから、以下のシナリオのテストを生成することに重点を置いてください:
1. 検索ボタンの表示確認 (Verify search button presence)
2. クリックで検索モーダルを開く (Open search modal via click)
3. Command+Kで検索モーダルを開く (Open search modal via Command+K)
4. 基本的な検索クエリの実行 (Execute basic search query)
これらのテストは tests/ ディレクトリにJavaScriptファイルとして生成してください。プロジェクトのセットアップについては、シードファイル tests/seed.spec.js を参照してください。
テストが以下のようになっていることを確認してください:
- JavaScriptで書かれていること(TypeScriptではない)
- 適切なロケーターとアサーションを使用していること
- 適切な待機と検証を含んでいること
Playwrightのベストプラクティスに従っていること
ジェネレーターエージェントの動作
ジェネレーターエージェントは以下の処理を実行します:
- テストプランの解析 - Markdownファイルからテストシナリオを抽出
- ブラウザの起動 - 実際にブラウザを動かして要素を確認
-
ロケーターの生成 - 適切なロケーター(
getByRoleなど)を自動選択 - テストコードの生成 - JavaScript形式でテストファイルを作成
-
ファイルの保存 -
tests/ディレクトリに保存
生成されたテストファイル
ジェネレーターエージェントが生成したファイル:
tests/
├── seed.spec.js # シードテスト(既存)
├── verify-search-button-presence.spec.js # ← 生成
├── open-search-modal-via-click.spec.js # ← 生成
├── open-search-modal-via-command-k.spec.js # ← 生成
└── execute-basic-search-query.spec.js # ← 生成
生成されたテストコードの例
1. 検索ボタンの表示確認
tests/verify-search-button-presence.spec.js
// spec: specs/検索機能テストプラン.md
// seed: tests/seed.spec.js
const { test, expect } = require('@playwright/test');
test.describe('検索ボタンの表示と基本UI確認', () => {
test('検索ボタンの表示確認', async ({ page }) => {
await page.goto('https://playwright.dev/');
// 1. Verify search button is visible in navigation bar
await expect(page.getByRole('button', { name: 'Search (Command+K)' })).toBeVisible();
// 2. Verify "Search" text is displayed on the button
await expect(page.getByText('Search')).toBeVisible();
// 3. Verify keyboard shortcut "⌘ K" is displayed on the button
await expect(page.getByText('⌘')).toBeVisible();
});
});
注目ポイント:
- ✅
getByRole('button')- アクセシビリティベースのロケーター - ✅
toBeVisible()- 待機付きアサーション - ✅ コメント付きで手順を明記
2. クリックで検索モーダルを開く
tests/open-search-modal-via-click.spec.js
注目ポイント:
- ✅
getByRole('searchbox')- 検索ボックスの正しいロケーター - ✅ UIの各要素を順番に検証
- ✅ テストプランの期待結果がそのままコードに
3. キーボードショートカット(Command+K)
注目ポイント:
- ✅
page.keyboard.press('Meta+k')- キーボード操作を正確に実装 - ✅ シンプルかつ効果的なテスト
4. 基本的な検索クエリの実行
注目ポイント:
- ✅
.fill('browser')- テキスト入力の実装 - ✅ 正規表現
/See all \d+ results/で動的な値に対応 - ✅ 検索結果の各要素を詳細に検証
生成されたテストの実行
実際にテストを実行してみます。
npx playwright test
実行結果
Running 5 tests using 4 workers
✓ [chromium] › tests/seed.spec.js:3:1 › seed
✓ [chromium] › tests/verify-search-button-presence.spec.js:7:3 › 検索ボタンの表示と基本UI確認 › 検索ボタンの表示確認
✓ [chromium] › tests/open-search-modal-via-click.spec.js:7:3 › 検索モーダルの開閉 › クリックで検索モーダルを開く
✗ [chromium] › tests/open-search-modal-via-command-k.spec.js:7:3 › キーボードショートカット(Command+K)の動作 › Command+Kで検索モーダルを開く
✗ [chromium] › tests/execute-basic-search-query.spec.js:7:3 › 検索実行と結果表示 › 基本的な検索クエリの実行
2 failed
3 passed (8.3s)
結果分析
✅ 成功したテスト(3つ):
- シードテスト
- 検索ボタンの表示確認
- クリックで検索モーダルを開く
❌ 失敗したテスト(2つ):
- Command+Kで検索モーダルを開く
- 基本的な検索クエリの実行
失敗の原因
テスト1: Command+K の失敗
Error: expect(locator).toBeVisible() failed
Locator: getByRole('searchbox', { name: 'Search' })
Expected: visible
Timeout: 5000ms
Error: element(s) not found
原因: キーボードショートカットが正しく動作していない可能性があります。これは実際の環境依存や、ブラウザのフォーカス状態によるものと考えられます。
テスト2: 検索クエリ実行の失敗
Error: expect(locator).toBeVisible() failed
Locator: getByRole('link', { name: 'Browsers' })
Expected: visible
Error: strict mode violation: getByRole('link', { name: 'Browsers' }) resolved to 7 elements
原因: 「Browsers」という名前のリンクが複数存在するため、Playwrightの厳密モードでエラーになりました。
ジェネレーターエージェントの特徴
✅ 良かった点
-
自動コード生成
- Markdownテストプランから自動でコードを生成
- 手作業でコードを書く時間を大幅に削減
-
Playwrightベストプラクティスに準拠
-
getByRole()などのアクセシビリティベースのロケーター - 待機付きアサーション(
toBeVisible()) -
waitForTimeout()などのアンチパターンを使用しない
-
-
実用的なコード品質
- コメント付きで読みやすい
-
test.describe()でグループ化 - 各テストが独立して実行可能
-
実際の動作確認
- ブラウザを動かしながら要素を確認
- 実在する要素に基づいてロケーターを生成
⚠️ 注意点と改善余地
-
初回生成では完璧ではない
- 5テスト中2テストが失敗
- ここでもう一つのヒーラーエージェントが活躍してくるのかも
- 環境依存やDOM構造の複雑さによる失敗あり
- 5テスト中2テストが失敗
-
厳密モードの制約
- 同じ名前の要素が複数ある場合、エラーになる
- より具体的なロケーターが必要
-
キーボード操作の検証
- キーボードショートカットのテストは環境依存性が高い
- でもコレはジェネレータエージェントが原因でも無いし、そんなに今回のと関係は無さそう
- 追加の調整が必要な場合がある
- キーボードショートカットのテストは環境依存性が高い
-
ヒーラーエージェントとの連携が重要
- 失敗したテストは、次のステップでヒーラーエージェントが自動修復
- ジェネレーターだけでは完結しない
プランナー → ジェネレーター のワークフロー
今回の一連の流れをまとめると:
ステップ1: プランナーエージェント(前回)
入力: Webサイト(Playwright公式サイト)
↓
処理: 自動探索とテストプラン生成
↓
出力: specs/検索機能テストプラン.md(556行)
ステップ2: ジェネレーターエージェント(今回)
入力: specs/検索機能テストプラン.md
↓
処理: テストコードの自動生成
↓
出力: tests/*.spec.js(4ファイル)
ステップ3: テスト実行
コマンド: npx playwright test
↓
結果: 3 passed, 2 failed
ステップ4: ヒーラーエージェント(次回予定)
入力: 失敗したテスト
↓
処理: 自動修復
↓
出力: 修正されたテストコード
従来の手作業との比較
| 項目 | 従来の手作業 | プランナー + ジェネレーター |
|---|---|---|
| テスト設計 | 数日〜1週間 | 数分(Planner) |
| コード実装 | 数日 | 数分(Generator) |
| 初期品質 | 担当者の経験に依存 | 60%(3/5成功) |
| メンテナンス | 手動で修正 | Healer で自動修復 |
| 言語対応 | 手動翻訳が必要 | 多言語自動対応 |
所要時間の比較:
- 手作業: 約3〜7日
- Test Agents: 約10分 + 修正時間
プロジェクト構成(最終版)
try-playwright-agent/
├── package.json
├── package-lock.json
├── playwright.config.js
├── node_modules/
├── tests/
│ ├── seed.spec.js # シードテスト
│ ├── verify-search-button-presence.spec.js # ✅ 成功
│ ├── open-search-modal-via-click.spec.js # ✅ 成功
│ ├── open-search-modal-via-command-k.spec.js # ❌ 失敗
│ └── execute-basic-search-query.spec.js # ❌ 失敗
├── specs/
│ ├── playwright-website-navigation.md # プランナー生成
│ └── 検索機能テストプラン.md # プランナー生成
└── test-results/
└── (テスト実行結果のレポート)
次のステップ: ヒーラーエージェント
失敗した2つのテストは、**ヒーラーエージェント(🎭 Healer)**を使って自動修復できます(はず(まだ試してないからわからんけど))。
ヒーラーエージェントは:
- 失敗したテストを再実行
- エラー原因を分析
- 適切な修正案を提案
- テストを自動修復
- (らしい)
次回はヒーラーエージェントを使って、これらの失敗を自動で修正する過程をお見せします。
まとめ
🎯 今回わかったこと
ジェネレーターエージェントができること:
- ✅ Markdownテストプランから実行可能なコードを生成
- ✅ Playwrightベストプラクティスに準拠
- ✅ 実際にブラウザで検証しながらコード生成
- ✅ 60%の確率で即座に動作するテストを生成
残る課題:
- ⚠️ 初回生成で100%成功するわけではない
- ⚠️ 環境依存のテスト(キーボード操作など)は調整が必要
- ⚠️ 複数要素のマッチングには追加の工夫が必要
参考リンク
検証日: 2025-10-10
Playwrightバージョン: 1.56.0
使用ツール: Claude Code + Playwright MCP Server
テスト成功率: 60% (3/5 passed)
今回の検証に使ったコードをgithubに上げてあります。よかったら手元で試してみてください(といっても生成された結果のファイル群なので試すもなにもないのだけど)
あと1つのヒーラーエージェントについてもトライ中なので、近日中に記事書こうと思います。
株式会社SKIYAKIのテックブログです。ファンクラブプラットフォームBitfanの開発・運用にまつわる知見や調べたことなどを発信します。主な技術スタックは Ruby on Rails / React / AWS / Swift / Kotlin などです。 recruit.skiyaki.com/
Discussion