VRT導入の効果と課題

そもそもVRTとは

Visual Regression Testing(VRT)は、デザインの変更が期待通りに行われているかを確認するための手法です。デザインの変更が行われた後に、変更前後のスクリーンショットを比較します。視覚的な変更や不整合を素早く発見することができます。

VRT導入のためにやったこと

リポジトリにプルリクエストを行うと、VRTによる見た目の差分結果レポートが自動連携される仕組みを構築しました。

この仕組みはreg-suitとstorybookを組み合わせて実現しました。これらの技術を選んだ理由は2点あります。

• storybookがプロジェクトに既に導入されており、見た目のテストが簡単に実現できる
• コストがかからない

導入にあたり、AzureDevOpsとの連携を可能にするプラグインの開発や、Azure BlobStorageへVRT結果を保存するためのサードパーティー製プラグインへプルリクエストも行いました。
また、自チームだけではなく他チームへの横展開を行いました。今ではプロジェクトのフロントエンド全体でVRTが稼働しています。

VRT導入の動機

VRTの導入に至った主な動機は以下です。

1. 学習コストが低い
   • storybookのstoryさえ書いておけば、プルリクエスト時にstoryに対して自動的にVRTが走ります。新たにテストの書き方を覚える必要はありません。
2. 信頼性の高いテストをやりたい
   • 書籍「単体テストの考え方」からの影響で、最終成果物を検証することこそが信頼性の高いテストに繋がるので私はこう考えました。最終成果物を検証することでテストの偽陽性が出にくいです。逆に偽陽性が多いと、開発者はテストを信用しなくなり活用されなくなってしまいます。VRTは実装の構造を一切テストせず、最終成果物の見た目だけをテストします。VRTは信頼性が高いテストだと考えています。
3. デザイン崩れの防止をしたい
   • 修正によるデザインの崩れが頻発していました。崩れが無いことを保証する手動テストは手間です。自動化により効率化できると考えました。
4. CSSのリファクタリングをしたい
   • 既存の複雑なCSSをリファクタリングしたいと考えていました。見た目のデグレを防ぎつつリファクタリングを進めるにはVRTが有益であると判断しました。

導入して分かった効果

VRT導入により想定外の良い効果が得られました。

1. 見た目変更の影響範囲が可視化できた

   • VRTはコードレビューだけでは分からない見た目の変更を自動検知します。リポジトリ内で広く再利用されているコンポーネントの変更時に特に役に立つことがわかりました。他のどのコンポーネントに変更が影響したかレポート通知から一目瞭然なため、波及した影響を的確に把握できるようになりました。

2. コードレビューの手間が減った

   • プルリクエスト内のVRT結果レポートから実装された見た目を簡単に確認できます。レビュワー側で開発環境を立ち上げて確認する手間が省けました。(コードレビュー内で画面の見た目をチェックすべきかは議論の分かれるところですが、、)

3. ライブラリ更新が楽になった

   • 他チーム事例です。既存で実装されている画面の挙動の単体テストを併せて行うことで、依存npmパッケージのアップデート時のデグレチェックを自動化することに成功しました。

課題

VRTの導入で以下の課題を認識しました。

1. 仕組みづくりの必要性
   • プロジェクト内の他チームでVRTの使い方の理解が不足しています。差分が検出されても無視されるケースや新規実装に対するStoryの書き忘れが見られました。
     • 別チームでは、新規実装コンポーネントにstoryが実装されていないプルリクエストが提出された場合に通知を行う仕組みを実装していました。これが良い対策になりそうです。
2. 使われるための工夫
   • 前述の差分が出ても無視されるケースはVRTが使われていないことと等しいです。使われていない原因は、具体的なVRTのメリットが十分に認識されていないことだと思います。プロジェクト内のメンバにVRTの利用方法とメリットについて具体的に共有し理解を深めていく必要があると考えています。