ビジュアルリグレッションテストと単体テストの違いは？

単体テストは、コードのロジックが正しい出力を返すか確認します。ビジュアルリグレッションテストは、描画されたUIの見た目を比較します。CSS変更でUIが崩れても単体テストが通る場合があり、画像比較はそのような差を見つける助けになります。

誤検出の原因は何ですか？

アンチエイリアス、OS間のフォント描画、時刻や広告などの動的内容、アニメーションのタイミングにより、不具合ではない画素差が生じます。

多くの場合に使われます。PuppeteerやPlaywrightなどから条件を固定して自動撮影し、基準画像と比較できます。画面表示ありのブラウザでも可能ですが、手動撮影は条件が変わりやすく、安定した比較には向きません。

時刻、利用者のアバター、広告、アニメーションなど、実行ごとに変わる領域をマスクまたは比較対象から外します。多くのビジュアルテストツールは、除外領域や要素のマスクに対応します。

UIに触れるプルリクエストやコード変更ごとにCIで実行すると、公開前に差を確認できます。実行頻度はテスト時間と変更リスクに合わせ、定期的な基準画像の確認も行います。

ビジュアルリグレッションテストは、変更前後のUIスクリーンショットを自動比較し、意図しない見た目の差を検出するテスト方法です。

撮影、比較、確認の順に進みます。まず、ページ、コンポーネント、特定のビューポートなど、各UI状態の基準画像を撮ります。これが期待する見た目を表します。

コードを変更したら、同じ条件で画像を再撮影します。テストツールが、新しい画像と基準画像を画素単位または知覚的なアルゴリズムで比べ、違う部分を示します。

差が見つかったら、人が内容を確認します。ボタンの再設計や色の更新など意図した変更なら、承認後に新しい基準画像とします。位置ずれやレイアウト崩れなど意図しない変更なら、リグレッションとして修正へ戻します。画像差だけでは、変更が正しいかどうかを判断できません。

この処理をCI/CDへ組み込めば、本番公開前に視覚的な差を確認できます。ただし、テスト対象、しきい値、レビューの質によって見逃しも起こり得るため、すべてのUI不具合を検出する保証はありません。

デザインシステム： 共有ライブラリのコンポーネント更新が、複数のアプリで使う見た目を意図せず変えていないか確認します
クロスブラウザテスト： Chrome、Firefox、Safari、Edgeで同じページを撮影し、ブラウザごとの描画を確認します。エンジンやOSによる正当な違いもあります
レスポンシブレイアウト： 複数のビューポート幅で画像を比べ、ブレークポイントが意図どおり動くか確認します
テーマ変更： ダークモード、ブランドカラー、書体の変更が、UIの別の箇所へ想定外の影響を与えていないか調べます
アクセシビリティ監査： コード変更後に、読みやすさ、コントラスト、フォーカス表示へ影響する見た目の差を探します。画像比較だけではアクセシビリティ要件を網羅できないため、ほかのテストと併用します

主な比較方法は、画素単位の差分と知覚的な差分です。

ピクセル差分は、対応する画素を1つずつ比べ、小さな違いも検出します。精密な一方、アンチエイリアス、サブピクセルの文字描画、アニメーションのわずかなタイミング差も誤検出になります。多くのツールでは許容しきい値を設定し、ノイズを減らせます。

知覚的差分は、人の目に近い基準で違いを評価しようとします。1段階の色差や文字描画のサブピクセルずれなど、目立ちにくい差を無視し、認識しやすい変更を中心に示します。誤検出を減らせる一方、非常に小さな不具合を見逃す場合があります。

実務では、最初に小さな許容値のピクセル差分を使い、テストが増えて誤検出の確認負担が大きくなったら、知覚的差分を検討する方法があります。

安定したテストには、固定フォント、決まったデータ、動的領域のマスクなど、変化しないテスト条件も必要です。条件が不安定だと差分を信頼できなくなり、テスト自体が使われなくなります。

動的な内容を安定させない： 時刻、ライブデータ、ランダムな内容、広告は撮影ごとに変わり、誤検出になります。領域をマスクするか、固定データを使います
異なる環境で実行する： macOSとLinuxでは、フォント描画、アンチエイリアス、ブラウザ初期値が異なります。同じコンテナなど、固定した環境で撮影します
許容値を上げすぎる： 誤検出は減りますが、本当のリグレッションも隠れます。低い値から始め、実際のノイズに合わせて調整します
基準画像を保守しない： UIが変われば、基準画像も古くなります。定期的に確認、更新し、すべての変更を自動承認せず、意図した更新か判断します