Upgrade to Pro — share decks privately, control downloads, hide ads and more …

共通コンポーネントのテスト実装方法にあえてVRTを選択した話 / why do we choose VRT for testing shared components

共通コンポーネントのテスト実装方法にあえてVRTを選択した話 / why do we choose VRT for testing shared components

Vue Fes Japan 2022 の発表内容です
https://vuefes.jp/2022/sessions/KushibikiMashu

■ 概要
社内のコンポーネントライブラリに対してStorybookとChromaticでビジュアルリグレッションテストを導入して、見た目のデグレを防止している話をします。

■ 詳細
Chromaticとは、Storybookのメンテナーが作成しているStorybook用のツールです。
ストーリーごとのスクリーンショットを撮影し、差分を画像で比較してくれる機能を備えています。

以下の課題を解決することを目的にして Chromatic を導入しました。

既存のコンポーネントを改修した際に発生する DOM、CSS に起因する表示崩れを自動で検知できないこと
依存モジュールのバージョンアップに時間がかかること
その結果、両方の課題を解決できた上に作業が楽になったという話をします。
また、なぜ他のテストではなくてビジュアルリグレッションテストを導入したのか、その意思決定の過程についても紹介します。

panda_program

October 16, 2022
Tweet

More Decks by panda_program

Other Decks in Programming

Transcript

  1. 1 © 2012-2022 BASE, Inc. #vuefes Vue Fes Japan 2022(2022.10.16)

    共通コンポーネントの テスト実装方法に あえてVRTを選択した話 プログラミングをするパンダ (@Panda_Program)
  2. 2 © 2012-2022 BASE, Inc. #vuefes 自己紹介 • BASE株式会社 •

    所属:BASE / Product Dev / CRM3 • 現在のお仕事:シニアエンジニア ◦ フロントエンドで React(Next.js)を書いたり Vue.js を書いたり ◦ バックエンドでは PHP を書いてます ◦ 最近は顧客管理機能(CRM)を開発してます • 好きなことと活動 ◦ DevOps とアジャイルの開発プロセス(特にXP)が好き ◦ Software Design 2022年3月号で TDD 特集の2,3部を執筆しました ◦ twitter: @Panda_Program プログラミングをするパンダ(@Panda_Program)
  3. 3 © 2012-2022 BASE, Inc. #vuefes 自己紹介 個人開発が好き プログラミングをするパンダ(@Panda_Program) ブログ書いてます

    https://panda-program.com/ ビールの画像投稿サイト作りました https://beerbreak.info/ Next.js + Vercel + Supabase
  4. 8 © 2012-2022 BASE, Inc. #vuefes 本発表の目標 アプリケーションに応じた最適なテスト 戦略を考えられるようになる 1

    手動テストを自動テストにする(テスト自動 化)ために考慮すべきことを知る 2 3
  5. 12 © 2012-2022 BASE, Inc. #vuefes 本発表の構成 BASEの共通コンポーネントの課題と 前提知識 1

    テスト実装方法の比較とVRTを選択した 意思決定 2 3 導入後10ヶ月間の運用結果とまとめ
  6. 14 © 2012-2022 BASE, Inc. #vuefes 共通コンポーネントの課題と前提知識 • ショップオーナーの管理画面を構築する ためのコンポーネント集である

    ◦ Vue2 で2018年1月から開発開始 ◦ 十分なコンポーネントが揃っている • ライフサイクルでいえば成熟期 ◦ 頻繁なアップデートはない ◦ メンテナンスは続いている • 有志のメンバーが手が空いた時間にメン テナンスの対応をしている(5名前後) 前提知識
  7. 15 © 2012-2022 BASE, Inc. #vuefes 共通コンポーネントの課題と前提知識 • テストがない ◦

    変更でコンポーネントを壊すのが怖い • 本体App側の影響範囲がわからない ◦ 共通コンポーネントを呼び出す側にも 自動テストがない • メンテナンスは続いているのでたまに変更 の要求がある ◦ デザインシステムとの差分を解消 ◦ 新しいPropsでバリエーションを追加 課題: 変更が怖い
  8. 16 © 2012-2022 BASE, Inc. #vuefes 共通コンポーネントの課題と前提知識 • Storybookは入っているが一手間かかる ◦

    プルリクエストにスクショを貼る ◦ レビュワーは master と feature ブ ランチの Storybook を見比べて検証 • 本体App側の影響範囲はそれでもわから ない ◦ コンポーネントが使われている箇所 に知識の差がある ◦ レビューの質が属人的 課題: 変更のレビューをしにくい
  9. 17 © 2012-2022 BASE, Inc. #vuefes 共通コンポーネントの課題と前提知識 • Dependabotは入っているが... ◦

    更新はパッケージごとで手間 ◦ Storybook で一通り動かせて、ブラ ウザのコンソールに JS エラーが出 ていなければ OK • 有志のメンバーの士気の低下 ◦ 週一でチーム定例がある ◦ 自分から手を上げたものの「まだ終 わっていません」と報告しなければ ならず気が重い 課題: 依存パッケージのアップデートに時間がかかる https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/heaviest_objects_in_the_universe/
  10. 32 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 • テスト対象はJSのロジック ◦

    関数やクラスメソッドが対象 ◦ Composition API や React Hooksも ◦ サーバー(Node.jsなど)で実行 ◦ 実行速度が早い • HTML と CSS はテスト対象外 • テストフレームワーク ◦ Jest / Vitest ユニットテスト(単体テスト)
  11. 33 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 • テスト対象は HTML

    + JS ◦ ユニットテスト + α ◦ ブラウザAPIやデータフェッチも ▪ click や input イベントなど ◦ サーバー(Node.jsなど)で実行 ◦ 実行速度はまあまあ早い • CSS はテスト対象外 • テストフレームワーク ◦ Testing Library / Test Utils インテグレーションテスト(結合テスト)
  12. 34 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 • テスト対象はアプリケーション全体 ◦

    ブラウザからサーバーまで ◦ ページ(URL)単位でテストする ◦ ブラウザ(chromiumなど)で実行 ▪ ユーザーに近い環境でテスト ◦ 実行速度は遅く壊れやすい(flaky) • テスト対象が広い ◦ データベースや外部との通信も含む • テストフレームワーク ◦ Cypress / Playwright E2E(End to End テスト)
  13. 35 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 • テスト対象は HTML

    + CSS ◦ E2Eテストの一種 ◦ ブラウザでスクショを撮り、   サーバーで画像を比較 ◦ 実行速度は遅い • JS はテスト対象外 ◦ Storybook で Play functions を使 えばある程度は可能 • テストツール ◦ reg-suit / Chromatic VRT(ビジュアルリグレッションテスト、画像回帰テスト) Visual testing for React, Vue, and Angular • Chromatic https://www.chromatic.com/features/test
  14. 36 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 テストレベルによる比較 [1], [2]

    フロントエンドエンジニアの視点から、正確性・網羅性よりわかりやすさを重視した表現にしている [3] フロントエンドで「Viewのコンポーネントに対するテスト」の意味で使われている。但し、テスト界隈ではコンポーネントテストはユニットテストを指す(「テスト 技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03」ISTQB p. 32 より) https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
  15. 39 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 • JS のロジックを切り出しにくい

    ◦ 共通コンポーネントは Vue 2.6 ◦ Composition API が使われていない ◦ クラスで state を利用したロジック を多用している • 何年も使われていてロジックは信頼でき る ◦ ロジックが変わることは滅多にない ◦ バグが出るたびに修正されてきた ユニットテスト(単体テスト)
  16. 41 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 • 全部のコンポーネントにテストを書くの が大変

    ◦ 直近で発生しているのはロジックの バグではなくCSS崩れ ◦ 共通コンポーネントの機能追加は活 発ではない • ROIが見合わない ◦ 投資対効果の点で疑問 ◦ 例えば5人、3ヶ月間でテストを書い ても、表示崩れを検出できない = outcomeに繋がらない インテグレーションテスト(結合テスト)
  17. 43 © 2012-2022 BASE, Inc. #vuefes • E2Eは範囲が広い ◦ ページにアクセスしたり、フォーム

    を提出して画面遷移するテストなど ◦ パフォーマンステストもE2Eテスト • スクショの差分比較(VRT)もE2E ◦ Cypress, Playwright ▪ × ページ単位の差分 ▪ ◦コンポーネント単位差分 • こちらを実施したい ◦ VRTは良いが惜しい テスト実装方法の比較とVRTを選択した意思決定 E2Eテスト - ページ単位のVRT(ビジュアルリグレッションテスト)
  18. 45 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 • VRTで開発者が表示崩れに気づける ◦

    修正は HTML や CSS がメイン ◦ JSのロジックが変わることは稀 • 差分比較がコンポーネント単位 ◦ レビューが簡単 • Storybook を書くモチベになる ◦ Storybook を書けばテストが動く ◦ 安心感UP E2Eテスト - コンポーネント単位のVRT(ビジュアルリグレッションテスト) Visual testing for React, Vue, and Angular • Chromatic https://www.chromatic.com/features/test
  19. 49 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 • 画像比較のOSS •

    比較結果の差分がわかりやすい ◦ エンジニア以外への共有がしやすい • 環境構築に一手間かかる ◦ 画像は別で準備が必要 ◦ 環境整備が必要がある ▪ CIでスクショを撮ってS3にアッ プするなど ▪ メンテチームはボランティアな ので、手間が少ない方がいい Reg Suit https://github.com/reg-viz/reg-suit
  20. 50 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 Chromatic • 画像撮影

    + 画像比較のSaaS • 導入が簡単 ◦ コマンド一つで導入可能 ◦ GitHub Actions で簡単に実行 ▪ CIに組み込める ◦ ただし、Storybook は必須 • ビルドごとにURLが発行される ◦ PRにURLが表示される ◦ 差分の有無を確認するだけ https://www.chromatic.com
  21. 54 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 Chromaticの導入準備 • マネージャーへの説明

    ◦ ここまでの以上の思考過程を共有 ◦ ダメだったらやめる選択肢もあり ◦ 無料枠でまず導入してみる • Storybook のコンポーネントを増やす ◦ Storybook の数が多ければ多いほどカバー範囲が広い ◦ コンポーネントのバリエーション(Variant)を作成 ▪ Props の組み合わせパターンをたくさん作った ◦ Play functions でモーダルの開閉や文字入力なども対応 + テスト可能に
  22. 56 © 2012-2022 BASE, Inc. #vuefes 導入後10ヶ月間の運用結果とまとめ 冒頭の課題を解決できた • 課題:

    変更が怖い ◦ スクショがあるので、予期せぬ変更 は入らないことがわかる • 課題: 変更のレビューをしにくい ◦ 差分をピンポイントで確認できる ◦ レビューがとても簡単になった • 課題: 依存パッケージのアップデート に時間がかかる ◦ 月に1度パッケージアップデート会 ◦ 動作確認とマージが1時間以下で可能 に
  23. 57 © 2012-2022 BASE, Inc. #vuefes 導入後10ヶ月間の運用結果とまとめ メンテナンスチームの感想 • 手元で

    Storybook を立ち上げていたが、 その必要がなくなった • 変更点をまとめて Chromatic で見れる • 変更があったコンポーネント数が表示さ れる • 差分が全て記録されているので安心感が ある • 人の目でわからないような細かい差分も 検知してくれた
  24. 66 © 2012-2022 BASE, Inc. #vuefes Special Thanks 資料レビューありがとうございました! 02さん

    (@cocoeyes02) mk0812さん (@mk0812__) Takepepeさん (@takepepe) broccoliさん (@nihonbuson)