Storybook と聞くと必ず Visual Regression Test（VRT） が頭をよぎると思います。
というのもプロダクト運用するなかで発生するコンポーネント修正によって発生するスタイル崩れを防ぐ手立てとして有効だからです。
プロダクトの運営歴が長くなると開発担当者も変わります。
プロダクトへの参画から日が浅い場合は、共通コンポーネントを修正した場合の影響範囲を網羅することは難しいでしょう。
VRT さえ整備されていれば、開発担当者は影響範囲を検知し、間違いや漏れなく修正を完了することが容易になります。
その精度は、100% ではないかもしれませんがプロダクトの安定的な開発という意味で VRT は強力なツールといえます。
本記事では Storybook を利用する前提で VRT を導入する場合の選択の一助にしていただければ幸いです。
VRT の実装方法は大きく分けて 3 つある
様々なアプローチがありますが、大きく分けて 3 つだと考えています。
- 公式のツールを使う
- オープンソースツールを使う
- テストフレームワーク + VRT 機能
紹介するツールは一例です。
他にも選択肢はあると思いますが、考え方の参考として捉えていただければ幸いです。
Chromatic
Storybook と最も親和性が高いツールです。
GitHub と連携し、Storybook のビルド成果物をアップロードするだけでテストが実行されます。
特徴
- Storybook との連携が最も深く、Story の変更を自動で検知してテスト対象にする
- クラウドベースで、テスト環境のセットアップや管理が不要
- コンポーネントとその依存関係を特定し、変更を検知する
- 大規模プロダクトだとすぐに有料のプランに変更する必要がある
- 公式のツールなのでメンテナンスコストも比較的少ないと考えられます
reg-suit
画像を比較して、差分を表示してくれる有名なオープンソースツールです。
過去に導入経験のある方も多いでしょう。
特徴
- Storybook の静的ビルド成果物 (または URL) を利用するように設定が必要
- CI/CD パイプライン内で完全に実行・完結できる
- 差分レポートを生成し、CI/CD のステータスに反映
- AWS S3 や Google Cloud Storage などの外部ストレージに画像を保存できる
- ツールのアップデートに伴うメンテナンスコストや学習コストが発生する
Playwright / Puppeteer + VRT ライブラリ
既存の E2E (End-to-End) テストフレームワークに VRT 機能を組み込むアプローチです。Playwright や Puppeteer は、ブラウザ操作の自動化に用いられるツールです。
特徴
- Storybook の URL にアクセスし、特定の Story を表示させてスクリーンショットを撮る処理の記載が必要
- E2E テストと VRT を同じフレームワークで管理できる
- Storybook の標準的な状態だけでなく、より複雑な操作を伴う状態の VRT も可能
- Playwright の場合、
toHaveScreenshot()のような組み込みの VRT アサーションが提供されている - ツールが増える分、メンテナンスコストや学習コストも高くなる傾向にある
Chromatic とオープンソースどちらが良いのか？
どのツールを利用するかの判断軸は多数ありますが、「利用範囲」「開発チームの規模や状況」「長期的な安定運用」という 3 つの観点が大切だと考えています。
判断基準① ： 利用範囲がエンジニアのみなのか？
端的に申し上げると「誰が VRT の結果を見るのか」です。
具体的には、開発環境を構築できないデザイナーがデザインの差分を確認ケースは考えらえます。
この時に Chromatic であれば、ツールが URL を発行してくれるので、Chromatic を閲覧できる権限さえあれば簡単に共有と確認ができます。
対して、オープンソースツールを利用していると Chromatic のような環境を作るためには少し手間がかかるかと思います。
よって、エンジニア以外がツールを利用するのかは判断基準になりうると考えています。
判断基準② ： 開発チームの規模や状況
サービス規模が大きく、開発が活発に行われている場合 Cromatic を利用すると無料の範囲を超えてしまう可能性が高くなります。
VRT の有用性について十分に議論されていない、ステイクホルダーの理解がえられない試験的に導入するような段階では Chromatic の有料プランを選択するのは難しいでしょう。
VRT の有用性を証明しなければならないフェーズであるなどの場合には、オープンソースを利用した開発を選択する必要があるかもしれません。
環境がずいぶんアップデートできてないような開発環境下ではカスタマイズ性が重視されることもあるでしょう。
その場合は、オープンソースでの実装を選択する必要があります。
ただ、その選択は相応のメンテナンスコストを覚悟する必要があるので十分にチームで議論してください。
そもそも論として、 VRT の環境を整備していく段階で環境を新しくするのか、環境に合わせてカスタマイズした VRT 環境を構築するか議論は必要かと考えています。
新規の開発で、サービス規模が小さい場合 Chromatic は無料かつ簡単に実装ができます。
対して、オープンソースはカスタマイズ性が高いですが、初期実装高ストやその後のメンテナンスコストが高いことを念頭におく必要があります。
判断基準③ ： 長期的な安定運用
どの方法を選んでもメンテナンスコストはかかります。
公式ツールに関しては、メンテナンスコストに加えてツールを利用する費用がかかります。
プロダクトがグロースしていくと当然費用も比例して増えていくことが予測されます。
対して、オープンソースはツールの利用費用はかかりませんが、メンテナンスコストやオープンソースの学習コストがかかり導入したオープンソースを理解できている人、もしくはそれを学習するための仕組みをチームで構築する必要が生じます。
オープンソースであるが故に、公式のツールと比較して Storybook が大きく更新された時のメンテナンス（更新）の対応に大きな時間をかけて対応しなければならないシーンが発生しやすくなります。
厳密にいえば、オープンソースを利用しても費用はかかります。（画像を設置しておくサーバーの費用やメンテナンスするための人件費など）ここでの「費用」はツールを利用するための費用です。
本格的な導入を検討する段階では比較する必要があると思いますが、本記事では詳細には触れません。
まとめ
これらのツールの中で、Storybook のエコシステムに深く依存し、最もメンテナンスの負担が少ないのは、開発元が提供する Chromatic です。手軽に導入し、開発体験の向上を最優先したい場合はこちらが強力な選択肢となります。
しかし、担当するプロダクトによっては特殊な制約があることも多いと考えます。
メンテナンスのコストを踏まえてカスタマイズ性の高いものを選択するのも良い判断だと考えます。
現在利用されている CI/CD 環境や、テストの実行頻度、今後どのようなテストを導入していくのか様々な視点から検討していく必要があります。
この記事が思考の助けになると幸いです。