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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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）

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

14 © 2012-2022 BASE, Inc. #vuefes 共通コンポーネントの課題と前提知識 ● ショップオーナーの管理画面を構築するためのコンポーネント集である ○ Vue2 で2018年1月から開発開始 ○ 十分なコンポーネントが揃っている ● ライフサイクルでいえば成熟期 ○ 頻繁なアップデートはない ○ メンテナンスは続いている ● 有志のメンバーが手が空いた時間にメンテナンスの対応をしている（5名前後）前提知識

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

17 © 2012-2022 BASE, Inc. #vuefes 共通コンポーネントの課題と前提知識 ● Dependabotは入っているが... ○ 更新はパッケージごとで手間 ○ Storybook で一通り動かせて、ブラウザのコンソールに JS エラーが出ていなければ OK ● 有志のメンバーの士気の低下 ○ 週一でチーム定例がある ○ 自分から手を上げたものの「まだ終わっていません」と報告しなければならず気が重い課題: 依存パッケージのアップデートに時間がかかる https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/heaviest_objects_in_the_universe/

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

34 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 ● テスト対象はアプリケーション全体 ○ ブラウザからサーバーまで ○ ページ（URL）単位でテストする ○ ブラウザ（chromiumなど）で実行 ■ ユーザーに近い環境でテスト ○ 実行速度は遅く壊れやすい（ﬂaky） ● テスト対象が広い ○ データベースや外部との通信も含む ● テストフレームワーク ○ Cypress / Playwright E2E（End to End テスト）

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

Slide 41

Slide 41 text

41 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 ● 全部のコンポーネントにテストを書くのが大変 ○ 直近で発生しているのはロジックのバグではなくCSS崩れ ○ 共通コンポーネントの機能追加は活発ではない ● ROIが見合わない ○ 投資対効果の点で疑問 ○ 例えば5人、3ヶ月間でテストを書いても、表示崩れを検出できない = outcomeに繋がらないインテグレーションテスト（結合テスト）

Slide 42

Slide 42 text

Slide 43

Slide 43 text

43 © 2012-2022 BASE, Inc. #vuefes ● E2Eは範囲が広い ○ ページにアクセスしたり、フォームを提出して画面遷移するテストなど ○ パフォーマンステストもE2Eテスト ● スクショの差分比較（VRT）もE2E ○ Cypress, Playwright ■ × ページ単位の差分 ■ ○コンポーネント単位差分 ● こちらを実施したい ○ VRTは良いが惜しいテスト実装方法の比較とVRTを選択した意思決定 E2Eテスト - ページ単位のVRT（ビジュアルリグレッションテスト）

Slide 44

Slide 44 text

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

54 © 2012-2022 BASE, Inc. #vuefes テスト実装方法の比較とVRTを選択した意思決定 Chromaticの導入準備 ● マネージャーへの説明 ○ ここまでの以上の思考過程を共有 ○ ダメだったらやめる選択肢もあり ○ 無料枠でまず導入してみる ● Storybook のコンポーネントを増やす ○ Storybook の数が多ければ多いほどカバー範囲が広い ○ コンポーネントのバリエーション（Variant）を作成 ■ Props の組み合わせパターンをたくさん作った ○ Play functions でモーダルの開閉や文字入力なども対応 + テスト可能に

Slide 55

Slide 55 text

Slide 56

Slide 56 text

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