Open6
『ビジュアルリグレッションテストツール４選！ユーザーが語る各ツールのメリット』LTに参加してみた🌟
まさぴょん🐱『ビジュアルリグレッションテストツール４選！ユーザーが語る各ツールのメリット』LT🌟
-
ビジュアルリグレッションテスト（VRT）ツールの選定や運用に携わるエンジニアの皆様にピッタリのイベントを開催します。
-
ノーコードでE2Eテスト自動化を可能にして、多くのソフトウェア開発現場の生産性を高めてきたMagicPodが、今回はビジュアルリグレッションテストツールの世界に深く潜り込み、コンポーネントテストレベルのVRTツールからE2EテストレベルのVRTツールまで幅広くご紹介します。
-
現在話題の４つのツールをピックアップし、それぞれの魅力と課題を、実際のユーザー体験をもとに紹介します。
-
独自の視点で各ツールの特徴を掘り下げることで、皆様に日々の開発業務に役立つ貴重な情報をご提供します。パネルディスカッションでは、ツール選定のポイントや効果的な運用方法について深く議論する予定！
-
このイベントは、VRTの精度や効果を高めたい開発者の皆さまにとって、実践的な知識と新たな視点を得る絶好の機会となるイベントです！
個別セッションテーマ
-
「reg-viz 配下の VRT ツール群 (仮)」Quramyさん
- reg-cli, reg-suit, Storycap といったツールについて、各ツールの誕生経緯や利用例などを紹介します。
-
「Storybookの実力をフル活用するChromaticの活用」sakitoさん(サイボウズ株式会社)
- Storybookと、Chromatic
-
「VRTのダークホースLostPixelについて」aijiさん(株式会社エイチーム)
- 社内で開発しているコンポーネントライブラリのVRTツールとしてLostPixelを導入しました。
-
「Playwrightで一番小さく始めるVRTと、次のステップの選択肢」Hirotaka Miyagiさん(株式会社ROUTE06)
- VRTの運用には多くの考慮事項がありますが、Playwrightを使えば一番小さくVRTの運用を始められます
- その方法と、その次に進むべき選択肢についても紹介します。
パネルディスカッションテーマ
- VRTがあって助かったシチュエーションはありますか？
- 実装、メンテはどなたが行なっているか？VRTで不具合を検出できていますか？
- VRTのテストケースの管理や、テスト結果の評価や可視化はどうされていますか？
まさぴょん🐱reg-viz 配下の VRT ツール群
VRT: スナップショット・Test
- reg-viz
reg-viz-tools の特徴
- 自前のCI環境で構築するなら、無料で使えます。
Visual Testingに対する考え方
- フロントエンドVRTに対する考え方
- Visual Testingの範囲を定義する
- Componentの
Visual Testingに対するスタンス
- Storybookのような Componentカタログ
-
修正の影響範囲が自分たちでは、追えなくなる時が、いつか来る。。。
-
「見た目がどのように変更されるのか」を
reg-viz
- テストコードから、画像を生成する
画像で設計している経緯
- 2016時点では、Angular
- 「画像比較」だけ機能追加すれば、VRTができる！
「画像」で分離しているため、
サポートしているツールについて
- 今のところ、公式サポートしているツールは、Storybookのみ。
Storycap
- Storybookを
storycap-testrun
- CLIではなく、ライブラリ
- Storybook TestRunner上で、画像を撮ってくれる。
reg-cli
- reg-viz のなかで、一番古いパッケージ
VRTの課題
reg-vizは、CI上でのみ実行させることで、VRTの課題を解決する
- CIから Reviewer に通知する
発表資料
関連リンク🌟
まさぴょん🐱Storybookの実力をフル活用するChromaticの活用
Chromatic(クロマティック)
- 無料で活用できるが、チームで使用するなら、エンタープライズがおすすめ。
- ブラウザ環境(Test Runner環境)を用意しなくても、ChromaticでどのWebブラウザの挙動を確認できる。
- Storybookがある前提
- Storybook Test というライブラリもある
- Storybook上で、E2EのようなTestができる。
Chromaticを導入した背景
- 次の3つを解決するためのChromatic導入
- VRTの実行だけが理由じゃない。。。
- Storybookの共有のしやすさ
- SSOと、カスタムドメインをChromaticに設定している
- デザインシステムの環境で、Storybookを活用した。
- VRTを起点としたデザインレビュー
- デザイン変更が多いので、目視での確認をある程度、自動化したかった。
VRTをどう利用しているのか？
- VRTでは、コンポーネントのパターンと見落としがちな状態の検知に使っている
- Storybook駆動開発となり、テストが一体になっていることで、運用するのが当たり前になっている🔥
Snapshot数を節約する
- なにも設定しないと
git pushごとに、Snapshot数が増加する
StorybookとChromatic
- Storybookに依存しない、E2Eテスト環境 (Beta版)
Storybookで、Chromaticの確認が可能に🌟
- localで確認できる！
まとめ
- VRT以外にも機能が豊富
- Figma ✖️ Storybook ✖️ Chromatic のツール連携
- Storybook以外のE2Eテストツールとしての機能
発表資料
関連リンク
まさぴょん🐱VRTのダークホースLostPixelについて
LostPixelの特徴
- スナップショット
- Playwrightベース
- マルチブラウザ対応
- Playwrightを書いて、カスタムできる
- 画像の比較・差分検索がオールインワンなツール
スナップショットの対応ツールが豊富
- さまざまなカタログ・ツールとの連携ができる(サポート)
- Storybook
- Ladle
- Histoire
OSSモードと、プラットフォームモード
- OSSモード
- 無料
- CIを自分で組む必要がある
- プラットフォームモード
- 有料
- ベースライン
推しポイント
1. 設定ファイルは、JS/TSで記述できる
- 撮影対象のページのリストや、各ページの撮影時の設定などを実行時に動的に生成できる。
2. Playwrightの要領で、撮影前の任意の処理を設定できる
3. しきい値や、待機秒数などのパラメータは、ページ・ストーリーごとに設定できる
- VRTあるあるの解決
- Lost Pixel では、
4. 撮影時に任意の要素をマスキングして、撮影できる
- ランダムなコンテンツや、
いまいちなポイント🥺
1. 公式のDocの情報量が少ない
- 凝ったことをしようとすると、SrcCodeを読むハメに。。。
- --helpみたいなオプションも整備されていない。。。
2. OSSモードでの差分のプレビュー機能が充実していない。。。
- 3種類の画像データが生成されるのみ。
- diff単体では、原因特定にまでは、至れないので、
実際の運用について
- 車内用のコンポーネントライブラリプロジェクトで利用
- Lost Pixelは、OSSモードで利用
- VRTは、
- VRTのためにStorybookを書くのは避ける
Storybook + カスタムページ
登壇資料
関連リンク
まさぴょん🐱Playwrightで一番小さく始めるVRTと、次のステップの選択肢
アジェンダ
- Playwrightが提供する VRTの機能紹介
- 一番小さく運用する上での
VRTの基本3フェーズ
- 撮影：スクリーンショットの撮影
- 比較：
- 差分確認：
- ちゃんとVRTをしようとすると、大変。。。
Playwrightで、小さく始めよう🌟
- Microsoft製の E2Eテストツール
- Auto-wait
- Codegen： ブラウザでの操作をコードに変換してくれる
- VSCodeがめっちゃいい！！
PlaywrightでのVER
撮影, 比較, 差分確認 すべてに対応可能です。
1. 撮影フェーズ
screenshot()で、撮影する
2. 比較フェーズ
toHaveScreenshot() で、比較フェーズ
3. 差分確認フェーズ
VRTを始める上での指針
-
どのツールを使う？インフラはなにを用意すればいい？
- 比較元のスクリーンショット、どうする？
- 差分確認のビューワーは、どのように用意する？
- GitHub の Artifacts
VRT Test 実践
1. Playwrightのテストファイル
2. package.jsonでの設定
3. GitHub Actionsのワークフロー
現状できないこと
- URLベース撮影であること。。。
解決の選択肢
- 自前実装
- OSSを活用したセルフホスト
- Saas
Storyに対して、スクリーンショットを撮りたい
- 自前実装： Storyのパスを列挙する
差分確認をより簡単にしたい
- 自前実装：
- ツールの採用： 比較・差分確認フェーズを reg-suitに切り替える
- S3バケットなどのストレージが必要
- Saasの採用：比較・差分確認フェーズを lost-pixel に切り替える
VRT基盤の運用コストをできるだけ下げたい。。。
- SaaSの採用：
VRT時間増加が大変になってきた時は？
- 撮影で時間がかかりすぎるようになってきた時は、並列実行
発表資料
関連リンク
まさぴょん🐱パネルディスカッションテーマ
1. VRTがあって助かったシチュエーションはありますか？
Quramyさん｜Engineer (@Quramy)の場合
- 100PRとかで、数件あるかないかぐらい
- 人間の目視で確認できない、CSSの罠を検知してくれた時
Sakitoさん｜サイボウズ株式会社 Design Manager (@sakito)
- Chromaticで、観ていると実装上ですぐに変更を確認できるのが嬉しい
- デザインシステムを作っているので、Visual面での品質を担保したい。
- 確認の心理ハードルが下がって、心理的に楽になっている。
- focusや、hoverした状態などまで、人の目で見るのは大変なので、自動化できるのが、ありがたい！
aijiさん｜株式会社エイチーム Engineer(@aiji42_dev)
- 差分をVRTで、Visual的に確認できるのが楽。
- Baselineが、リポジトリにあるのは、そのまま確認できるので楽
Hirotaka Miyagiさん｜株式会社ROUTE06 Tech Lead (@MH4GF)
- Chakl UI (UIライブラリ) の Updateで、罠のような Updateがあった時に、それを検知してくれたのがありがたかった。。。
- スナップショットと、期待値Checkで、
- 最後の砦として、VRTは安心感がある。
2. 実装、メンテはどなたが行なっているか？VRTで不具合を検出できていますか？
Quramyさん｜Engineer (@Quramy)の場合
- Codeベースを触る人が自然と担当している。
- なので、役割分担まで考えたことがない。。。
- E2Eレベルのテストケースを考える段階になって、初めて、役割分担を考える。
- Storybookぐらいの単位なら、実装者が作成する
- 1個の storyファイルの中に、どれくらい storyを書くか？ について
- ちょっと重たいUnitテストみたいな感じで、StorybookでのTestは作っている
Sakitoさん｜サイボウズ株式会社 Design Manager (@sakito)
- Storybook と Chromaticを中心に関わるエンジニアや、デザインナーが実装・メンテをしている。
- なので、関わる人を合計すると、30〜40人ぐらいいる。
- デザインシステムを実装・メンテする専属人員も社内に入る。
aijiさん｜株式会社エイチーム Engineer(@aiji42_dev)
Hirotaka Miyagiさん｜株式会社ROUTE06 Tech Lead (@MH4GF)
- ストーリーの変更があるのに、VRTの変更がない場合
- パフォーマンスの
- FrontEnd書くときは、Test書いてね
- E2Eテスト
- 業務プロダクトだと、Playwightだけだと厳しい場合があるので、
- Playwrightは、E2Eテストで使っています。
3. VRTのテストケースの管理や、テスト結果の評価や可視化はどうされていますか？
Quramyさん｜Engineer (@Quramy)の場合
- テストケースの管理については、質問者の意図がわからないので回答が厳しいです。。。
- 結果の可視化については、差分のレポートで確認している。
- パフォーマンスの測定
Sakitoさん｜サイボウズ株式会社 Design Manager (@sakito)
- Chromaticがすべて解決してくれているので、特になにもない。。。
- ここら辺のことを考えるのが、面倒だから、Chromaticを使っている。
aijiさん｜株式会社エイチーム Engineer(@aiji42_dev)
- 可視化に関しては、差分として上がってくる分でしか見えていない。。。
- Storybookを見れば、基本の可視化はできているので、そこまで困っていないかも。
- テストケースの管理に関しては、Storybookに紐づいているので、それが管理状態にもなっている。
Hirotaka Miyagiさん｜株式会社ROUTE06 Tech Lead (@MH4GF)
- 可視化の部分は、
- 管理は、どれをVRTにするか？は、相談している
- デフォルトのStory