テスト種別（UI・ビジュアル）

UIテストはコンポーネントが正しく描画・操作できるかを検証するテストだ。機能テストが「ロジックが正しいか」を問うのに対し、UIテストは「ユーザーが見て・触れるインターフェースが意図通りか」を問う。Webフロントエンドにおいては、Reactなどのコンポーネントのレンダリング結果・インタラクション・スタイルの全てが検証対象になる。

スナップショットテストはコンポーネントのレンダリング結果をシリアライズしてファイルに保存し、次回実行時との差分を検出する。JestやVitestでtoMatchSnapshot()として提供されている。変更の検出は容易だが、スナップショットを機械的にupdateする習慣が根付くと意図しない変更の検知機能が形骸化する。ビジュアルリグレッションテストはスクリーンショットのピクセル差分を比較する手法で、Chromatic・Percy・reg-suitが代表的なツールだ。

Storybookはコンポーネントの独立したカタログを作成し、デザイナーとエンジニアの協働ベースになる。play functions機能を使えばStorybook上でユーザーインタラクション（クリック・入力等）を定義してテストできる。Storybookのストーリーをvitest-storybookでユニットテストとして実行する統合も進んでいる。レスポンシブ対応やモバイル表示のビジュアルテストもViewport設定で可能だ。

コードレビューで着目するポイント

スナップショットファイルの差分が意図した変更だけを反映しているか
スナップショットが肥大化してレビュー不可能なサイズになっていないか
ビジュアルリグレッションテストの感度閾値が誤検知・見逃しのバランスで設定されているか
Storybookのストーリーがコンポーネントの代表的な状態（エラー・ローディング・空状態等）を網羅しているか
play functionsでのインタラクションテストがユーザーの操作を正しく模擬しているか
レスポンシブ対応のビジュアルテストが主要なBreakpointをカバーしているか
ビジュアルテストのベースライン更新プロセスがレビュー済みの変更だけに限定されているか

典型的なアンチパターン

スナップショットの形骸化: テスト失敗時に内容を確認せずjest --updateSnapshotを実行する習慣が定着する。意図しない変更も全てスナップショットに取り込まれ、リグレッション検出機能が失われる。

ビジュアルテストのノイズ過多: アンチエイリアスや動的コンテンツ（日付・ランダムID）が含まれることでスクリーンショット差分が常に発生する。確定的なデータでStoryを構築し、動的部分はモックする必要がある。

Storybookのメンテナンス放棄: コンポーネントが変更されてもStorybookのストーリーが更新されず、実際のコンポーネントと乖離したカタログが残り続ける。Storybookをテスト基盤として使わないと更新のインセンティブが失われる。

参考リソース

Storybook https://storybook.js.org — コンポーネントカタログと相互作用テスト
Chromatic https://www.chromatic.com — Storybookと統合したビジュアルリグレッションSaaS
Percy（BrowserStack）https://percy.io — ビジュアルテスト自動化
reg-suit https://github.com/reg-viz/reg-suit — OSSのビジュアルリグレッションテスト
Playwright コンポーネントテスト https://playwright.dev/docs/test-components