🙃

VRTを導入して1ヶ月経ったので振り返ってみる

2024/07/05に公開

はじめに

今いる現場の新規開発系のプロジェクトでVisual Regression Test(以下VRT)を導入してみまして、
私としても組織としても運用するのは初であったので、
1ヶ月程経ったタイミングでチームの方と振り返ってみた結果をまとめてみました。

前提

VRTとは?

UI差分を検出する自動テストの手段の1つです。
主にフロントエンド開発において効力を発揮します。

以下はボタンの角の丸みを変更した際の差分を検知したデモです。
※実際の現場のものではなくイメージです。

VRT自体の詳しい解説は以下などをご参照ください。

https://zenn.dev/loglass/articles/visual-regression-testing-comparison

開発環境

  • 開発チームの人数は4-5人規模
  • 01の実装フェーズである
  • reg-suit + Storycapの構成で導入している
  • reg-cliを一部カスタムしている
    • 主に対象Repositoryの構成都合

効果

デザイン変更対応時の差分チェックが容易になった

恐らくVRTの効果として一番に思い浮かべるのがこちらかと思います。
例えば、既に実装した成果物の見た目の変更依頼が来ることがあります。
そう言った際に、自分の変更した差分が視覚的に現れるので、実装の質と効率が上がったと感じました。

CSSのリファクタが容易になった

  • 冗長な指定を消す、など軽微なCSSのリファクタを行う
  • 関連するセレクタへのCSSを変更する
  • CSS設計そのものを変更する

このようなケースの際に、意図せぬ見た目の差分が出ていないことを検知できるので、
安心してCSS、更にはテンプレートを改修することができました。

チーム内でデザイン変更の合意が取りやすくなった

例えば自分がPRを出した時、ここに差分が出てることがVRTの結果を見て貰えばすぐにわかるので、双方で認識を合わせるのが容易になりました。
逆に自分がレビュアーになった際には、PR作成者の変更箇所が一目でわかるようになったので、レビューの効率も格段に上がりました。

VRTの精度を意識することで、関連する技術や実装における感度が高まった

例えば私の現場ですとStorycapを用いているので、
VRTのためのソースコードを用意しようとすると、
Storybookの仕様を理解する必要が出てきたり、見た目を強制的に意識できたりと、
関連する事柄への知見もキャッチアップできると感じました。

改善したい点

VRTの仕組みが複雑になりがちで、有識者でないと整備ができない状態になりやすい

私が執筆時点(2024/07/05)で把握している限りでは、VRTの仕組みを導入するのに複雑な構成を取る必要があるケースが多いと感じています。
ここで複雑というのは、例えば以下を指しています。

  • そもそも仕組みが一見しただけだと難解
    • 比較に使用しているツール
    • 比較の仕組み
    • 実行スクリプトの仕組み
    • etc...
  • インフラのリソースも用意する必要がある。
    • S3など

CIテストというのは複数人での開発における効率化向上の手段と私は考えており、また、資産として残るものでもあると考えています。
そこに求められるものは、属人化しない仕組みであり、VRTは運用もしっかり視野に入れないとそこに抵触しかねるものだと感じました。

例えば

  • 仕組みに関する知見を継承できる、仕組みも用意する
    • ドキュメントを残す
    • メンバーへのオンボーディングを行う
    • など
  • 仕組み自体を捨てやすい状態となるように導入する
    • 開発そのものに対する負債にならない状態にしておく

この辺りを意識した上で導入を図るとより生産的なチームを長く維持することができると思いました。

快適を求めていくと独自スクリプトの必要性が大きくなる

所謂痒いところに手が届かないケースが散見されました。

例えば、執筆時点でメジャーなツールとしてはreg-cliがありますが、
こちらをFork運用やmonorepo構成でのRepositoryで動かすには、幾らか独自でスクリプトを用意する必要がありました。
※詳しくは以下の記事に記しております

https://zenn.dev/yu_ta_9/articles/6fb31dd82a6ef6

また、独自スクリプトを挟むと

  • pushの度にVRTのコメントが表示される
  • 最新のスナップショットのデータがないケースが起き、不正な結果が出る
    • あるPRをVRT完了前にマージしてしまった時など

など更なる痒みが出て、それを抑えるために更にスクリプトを・・・というイタチごっこになりやすいと感じました。

まとめ

  • VRTによるフロントエンドの開発効率の恩恵は大きい
  • 但し、動く仕組みが複雑になりがちなので、有識者でないと整備ができない状態になりやすい
  • 不正な動作が現れたときなどに、誰でも対応可能なよう、VRTの仕組みをチームに継承させる仕組み、慣習が必要

後書き

VRT自体は、フロントエンド開発においてとても有用と感じているので、
より安全安心に導入していけるように試行錯誤していきたいですね🙏
ご意見、ご提案などがございましたらお気軽にコメントいただけたら嬉しいです!

Discussion