導入
E2Eテスト運用における最大の敵は「Flaky Tests（不安定なテスト）」です。ローカル環境では成功するのにCI環境ではたまに失敗する、という現象に頭を悩ませた経験は誰にでもあるはずです。原因の多くは要素のレンダリング待ちや、非同期処理の競合です。本記事では、Playwrightの強力なデバッグ機能である「Trace Viewer」を活用し、テスト失敗時の原因特定を劇的に効率化する方法を解説します。
基礎知識
E2Eテストにおける「タイムトラベル・デバッグ」とは、テスト実行中の全ステップを記録し、失敗した瞬間のDOM状態、ネットワークリクエスト、コンソールログ、スクリーンショットを後から詳細に確認できる機能を指します。
Playwright Trace Viewerは、これらの情報を単一のファイル（.zip）に集約し、ブラウザ上でインタラクティブに再現できるツールです。これにより、CI上のテストが失敗した際、わざわざ再現環境を構築し直さなくても、ブラウザ上でクリック操作を追体験するように原因を特定できます。
実装/解決策
PlaywrightでTrace Viewerを有効にするには、設定ファイル（playwright.config.ts）でトレースの保存設定を行うだけです。これにより、テスト失敗時に自動的にトレースファイルが生成されます。
サンプルプログラム
以下のコードは、playwright.config.tsでトレース出力を設定する例です。
// playwright.config.ts
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
// テストが失敗した際にトレースを記録する設定
// ‘on-first-retry’: 初回失敗時に再試行し、その際にトレースを残す
// ‘retain-on-failure’: 失敗したテストのトレースを保持する
use: {
trace: ‘retain-on-failure’,
screenshot: ‘only-on-failure’, // 失敗時のみスクリーンショットを保存
video: ‘retain-on-failure’, // 失敗時のみ動画を保存
},
});
// テストコード実行時のコマンド
// npx playwright test –trace on （すべてのテストでトレースを有効にする場合）
// npx playwright show-report （生成されたレポートからトレースを開く）
応用・注意点
現場で活用する際のポイントをまとめます。
1. トレースファイルの取り扱い
CIツール（GitHub Actionsなど）を使用している場合、生成されたトレースファイルを「Artifact」としてアップロードしてください。これにより、CI上の失敗ログから直接トレースファイルをダウンロードし、手元のブラウザで「trace.playwright.dev」にドラッグ＆ドロップするだけで確認が可能です。
2. 「待ち」の戦略を見直す
トレースを見て「要素が見つからずにタイムアウトしている」ことが判明した場合は、固定のsleep（待機）を入れるのではなく、Playwrightの自動待機機能が働くよう、セレクタの記述をより堅牢なもの（例: data-testidの活用）に変更してください。
3. 容量制限に注意
大規模なテストスイートで常に全テストのトレースを残すと、ストレージを圧迫します。本番環境やCIでは「失敗時のみ」保存する設定を徹底するのが運用のコツです。
この手法を取り入れることで、デバッグに費やしていた時間を大幅に削減し、より安定したテスト環境を構築できるはずです。ぜひ試してみてください。
コメント