Claudeが実装したE2Eテストをレビューするツールを自作してみた

記事の概要

エムスリーのQAチームでは、開発経験のないQAエンジニアもClaudeを使ってPlaywrightのE2Eテストを実装している。しかしClaudeが書いたコードは「テスト実行は成功するのに、テスト手順や操作対象が誤っている」ことがあり、振る舞いの正しさは人がチェックする必要がある。自分で実装する場合は画面を見ながら書くので直感で分かるが、AI生成コードでは例えば次のようなコードの削除対象が正しいか確認するのに一手間かかる。

await page.getByRole('row', { name: orderId }).getByRole('button', { name: '削除' }).click();

そこで著者は「Claudeが実装したE2Eテストが期待通りの手順かをレビューするツール」を自作し、その設計と工夫を紹介する記事となっている。

Trace Viewerではなく自作した理由

Playwright公式のTrace Viewerは高機能だが、「テストの流れをざっと眺めて意図通りの実装かレビューする」用途には下記の課題があった。

• 操作対象がどこか確認するには1ステップずつクリックする必要がある
• ファイル・メール本文・APIレスポンスなど画面を伴わない検証は可視化しづらい（testInfo.attach()で出せるがフラットな一覧になり、どの手順に対応する検証か分かりにくい）

そのため「スクロールだけで実装内容を一覧できること」「画面のない検証もテスト手順に紐づけて見せること」の2点に特化したツールを自作した。

ツールの機能と工夫ポイント

1. 一覧画面・詳細画面

• 一覧画面：実行結果サマリー＋ファイル・describe・testごとの一覧。気になるケースをクリックすると詳細へ
• 詳細画面：テスト手順ごとにハイライト付きスクリーンショットが並ぶ

2. UIに対する操作

• PlaywrightのLocator/Pageの操作をラップし、クリックや入力・アサーション実行の直前に対象要素をハイライトしたスクショを撮影
• fill→「テキストを入力する」、toBeVisible→「表示されていることを検証する」のように、API名を自然言語ラベルに変換して表示
• beforeEachは「Before Hooks」区分にまとめ、各test.stepの見出しがステーブルの行見出しになる

3. 要素が見つかる検証（リトライ対策）

• アサーションは自動リトライすることがあり、検証直前のスクショには古い状態が映る恐れがある
• そこで所要時間が一定以上（＝リトライ発生）のときだけ検証成立瞬間のスクショも追加撮影し、「検証直前／検証後」をタブで切り替え可能にした
• ハイライト前に対象要素をblock: 'center'で画面中央にスクロール。アサーション系は自動スクロールされないうえ、上端合わせだとstickyヘッダーの裏に隠れるため

4. 要素が存在しないことの検証

• not.toBeVisibleやtoHaveCount(0)など非存在系はハイライト対象の位置が取れない → ページ全体のフルページスクショ＋「ページ全体」バッジで表示
• 存在しない要素へスクロールすると30秒タイムアウトまで固まるため、先にcount()で要素数を確認し0件ならスクロール自体をスキップ

5. page.goto（ページ遷移）

• 遷移先URLを添えて遷移後の画面をそのまま撮影（枠ハイライトなし）
• gotoのデフォルト待機はloadイベントまでのため、撮影直前に最大3秒だけ通信が落ち着くのを待つ処理を追加。ポーリングし続けるSPAで落ち着かない場合はタイムアウトを無視して撮影

6. UIのない操作・検証

• APIレスポンス検証・ダウンロードファイルの中身検証・メール本文検証などLocatorを介さない検証には専用ヘルパー関数を用意し、テスト側から明示的に呼び出す形式
• APIレスポンスは特定フィールドの検証結果を表示
• ファイルダウンロードはファイル名・サイズ・中身をまとめて表示
• 長いテキストの部分一致検証では実際に一致した箇所だけハイライトし、「本文のどこを見て検証が通ったか」が一目で分かる

使い分け：CIの失敗調査は引き続きTrace Viewer

• パフォーマンス：スクショ撮影＋ハイライト処理に1回あたり数百ミリ秒以上かかる → レビューツールは環境変数を明示指定したときだけ動作し、通常のCI実行では一切動かない
• 副作用：ハイライト枠の描画のため、撮影の瞬間だけページDOMに要素を一時挿入し撮影後すぐ除去する実装。プロダクトを改変していない状態で実行したいCIではTrace Viewer（副作用なし）を使う

想定外の活用法：Claude自身の自己検証

Page Objectのリファクタリング時に、一番怖いのは「セレクタの書き方を変えただけのつもりが、実は別の要素を掴んでいた」ケース。そこでリファクタリング前後でそれぞれレポートを生成し、ハイライト付きスクショをClaude自身に見比べさせて「同じ要素をハイライトしているか」を確認させる運用をしている。

まとめ・ポイント

• AI生成テストコードは「実行は成功するが手順・対象が誤っている」リスクがあり、人による振る舞いレビューが仍然必要
• 「スクロールで一覧できる」「画面のない検証も手順に紐づく」に特化したレビュー用ミニツールが有効
• リトライ・非存在検証・ページ遷移・UIなし検証など、Playwrightの細かい挙動に応じた工夫が詰まっている
• 著者自身は開発業務の経験者ではないが、Claudeを使えば数日でこのツールを作れた。AI時代にはちょっとした便利ツールを自作するハードルが大きく下がっている