Playwright Visual Comparisonsを活用し、効率的でより安全な開発環境を作る

背景と課題認識

• フロントエンドテストは、UI変更や予測不能なユーザー入力により難しさが多い。
• 人手による検証には限界があるため、自動化テストの導入を検討。
• 既存の録画方式のE2Eテスト（TestProject、Playwright）は、保守コストが高く、UI変更に弱い。

Playwright Visual Comparisonsの導入

• UIの変化を検知するビジュアルリグレッションテスト方式を適用。
• 基準スクリーンショットを保存し、コード変更後に比較して変更点を検出。
• 2-up、Swipe、Highlight、Onion Skin方式で画像比較が可能。

導入過程で経験した主な問題と解決策

1. わずかな差異（0.01%）による偽の失敗が発生
   問題: テスト実行環境（OS、ブラウザ、ディスプレイ設定など）によりフォントレンダリングの差異が発生。
   解決: Dockerコンテナを活用し、すべてのテストを同一環境で実行。

2. データ読み込み完了後にスクリーンショットを撮る必要がある問題
   問題: ページが完全に読み込まれる前にスクリーンショットを撮ると、ローディングUIが含まれることがある。
   解決: getByText + toBeVisible を活用するユーティリティ関数で、特定の文字列が現れるまで待機。

3. アニメーション要素によってスクリーンショット差異が発生
   問題: CSSアニメーション、Canvas、SVG、WebGL要素が毎回異なるタイミングでキャプチャされ、flaky testになる。
   解決: アニメーション無効化のための各種対応と、追加のテスト実行効率化を実施。

4. サードパーティプラグイン（iframeなど）による不要な変更検知
   問題: 顧客フィードバック、アンケート、チャットボットなどのサードパーティプラグインがiframe経由で読み込まれ、視覚的変化を生む。
   解決: スクリーンショット生成時に共通CSSを適用し、iframeと特定プラグイン要素を非表示にする。

5. スクロールのあるページで下部要素の検証に失敗
   問題: toHaveScreenshot は基本的に現在表示されている画面だけをキャプチャするため、スクロール関連の処理が必要。
   解決: fullPage: true オプションを適用し、ページ全体のスクリーンショットをキャプチャするよう設定。

結論

• ビジュアルリグレッションテストにより、UI変更検知を効果的に自動化。
• 完璧なソリューションではないが、開発生産性とテスト安定性の両方を向上。
• 継続的な改善とテスト環境の最適化が必要。