Misocaにおけるビジュアルテストへの取り組み

Misocaにおけるビジュアルテストへの取り組み株式会社Misoca 森俊介

$ whoami 森俊介 / 黒曜 @kokuyouwind 株式会社Misoca 一応Railsエンジニア最近はTerraformとかDockerを
よく触っている

突然ですが

自動テストしてるよって人 🙋

E2Eの自動テストしてるよって人 🙋

デザインの自動テストしてるよって人 🙋

CSSの問題検知は難しい 🤔 marginすこし弄ったけど、使ってるところは確認したし CI Greenだから大丈夫だよね……

結果……

真ん中に出るはずのモーダルが下にずれたこの下にあるボタンが押せなくなってる 😢

＿⼈⼈⼈⼈⼈⼈＿＞突然の死＜￣Y^Y^Y^Y^Y^Y^ ￣

なぜ気づけないか？ feature specではDOM構造を検査するデザイン崩れはほぼ検知できない影響範囲がグローバル classの命名規約が適切でないと、どこに影響するかがわからない grepで見つけられるかというと…… div.container li
> a とか……

そこでビジュアルテストですよ！

ビジュアルテストって？ビジュアルリグレッションテスト (Visual Regression Testing)が正確「見た目」に対するテストキャプチャ画像などのdiffを検査する

ビジュアルテストのレポート

Agenda ビジュアルテストの概要 Misocaでの活用事例の紹介運用での工夫や注意点今後の展望・活用アイディアまとめ

ビジュアルテストの流れ 1. 現在の外観をキャプチャ 2. 正答画像の取得 3. 画像の比較・レポート

各ステップごとにいくつかのやり方がある

手法分類ー外観キャプチャテストしたい単位で描画コンポーネント単位など一時サーバでキャプチャ Feature SpecでのRackサーバなど実環境でキャプチャ

テストしたい単位で描画 Pros. コンポーネント単位で差分が出せるデータを自由に変えやすいサーバアクセス不要なので早い(はず) Cons. 実際の画面単位の描画とは多少差がある RailsのPartial Viewでは工夫が必要

一時サーバでキャプチャ Pros. 既存のE2Eテストに組み込める(かもしれない) データを自由に変えやすい実際の画面単位でキャプチャできる Cons. 必要な単位での描画と比べると重いランダム要素があると、E2Eテストと同居できない

実環境でキャプチャ Pros. 導入しやすい簡単にページを開いて確認できる Cons. 実アプリ上でデータの準備・保守が必要時間経過などで見た目が変わると使えない表示が恒常的に変わる操作はテストできない

手法分類ー正答画像の取得正答画像を別途保存人間が都度判断して更新する前回のキャプチャと比較分岐元のキャプチャと比較 gitのコミットごとに画像を貯めておく git branchが分岐した元の画像と比較する

正答画像を別途保存 Pros. 正答データと確実に比較できる Cons. 正答データが変わると更新が必要

前回のキャプチャと比較 Pros. 自動で正答データが最新になる Cons. 一度差分を見逃すと、次回以降検知できない検知した差分を修正したときも差分が出る

分岐元のキャプチャと比較 Pros. PR単位でmasterからの差分を確認できる自動で正答データが更新される Cons. 運用環境でのテストでは使えない Gitの分岐元判定が難しい

画像の比較・レポートここは大差ない画像diffツールに何が使われるかくらいレポートは大抵HTMLで出てくる誤差許容パラメタのほうが重要差分をどの程度許容するか(px/%) 色の違いをどの程度まで一致とみなすか

どれがいいの？それぞれ向き・不向きがある運用環境でリリース毎や定期的に見るのか PR単位でmasterからの差分を見るのかツールによって担当範囲や手法が違う

ビジュアルテストツール reg-suit 正答データ管理や通知をカスタマイズできる現在の外観画像は別途用意が必要 BackstopJS 外観画像取得から比較まで全部やってくれる実環境へのWebアクセス+正答データ明示のみ Storybook コンポーネント単位でレンダリング

目的に応じて適切な方法を組み合わせる必要がある

Agenda ビジュアルテスト手法の分類 Misocaでの活用事例の紹介運用での工夫や注意点今後の展望・活用アイディアまとめ

Misocaでのビジュアルテスト本番環境・ステージ環境のキャプチャ実環境で前回との差分チェックローカル環境のキャプチャ実環境で正答データとの差分チェック帳票PDFのキャプチャ PDFを描画し、正答データとの差分チェック

本番環境日次で、前日との差分を検知キャプチャ: capybara-screenshot 正答管理: reg-suit simple-keygen(Jenkinsビルド番号をキー) 差分レポート: reg-suit Slackの専用チャンネルに通知
差分があったら、問題ないかを見てスレッドに書く

Slack通知

reg-suitのレポート画面(再掲)

ステージ環境リリース毎に、前回との差分を検知本番環境と同じ仕組みキャプチャ: capybara-screenshot 正答管理: reg-suit simple-keygen(Jenkinsビルド番号をキー) 差分レポート: reg-suit
リリース作業チャンネルに通知差分があったら、問題ないかを見てスレッドに書く

Slack通知

ローカル環境必要なときに手動で実行キャプチャ: BackstopJS 正答管理: BackstopJS(init, approve) 差分レポート: BackstopJS

なぜ本番・ステージと違う？ローカルで表示しづらい画面がある外部連携など環境によって描画に微妙な差が出る正答データが集約できない Dockerを使えば解決しそう CSSを書く人がJavaScriptに慣れていた

帳票PDF 通常CIで、正答データとの差分を検知キャプチャ: MiniMagickでpdf -> pngに変換正答管理: Gitコミット(approveモード実行で上書き) 差分レポート: MiniMagick
失敗した場合はPR Statusに反映他のテストが失敗したときと同じ

帳票PDFのdiff

なぜ帳票だけ？ Misocaのサービス上重要な部分個別に整備する価値がある現在手を入れている箇所なので、安心して触りたい PDF生成処理が独立しているデータを変えて網羅的にテストしやすい

環境に応じて色々やってるステージ環境が防衛ライン最悪でも本番で日次検知

キャプチャ時の注意点 CSSでアニメーションやキャレットを切る非同期読み込みは少し長めに待つ画像も長めに待たないと出ない事がある画面や状態がわかる画像名にする「請求書編集画面-プルダウン-発行.png」などルールを作ってヘルパーメソッドを作ると良い

CSSでアニメーションを切る def disable_animations page.execute_script(ANIMATIONS_DESABLE_SCRIPT) end ANIMATIONS_DISABLE_STYLE = <<~CSS  CSS ANIMATIONS_DESABLE_SCRIPT = <<~"SCRIPT" const style = document.createElement('style'); style.innerHTML = `#{ANIMATIONS_DISABLE_STYLE}`; document.head.appendChild(style); SCRIPT

テストコード module Pages module Invoices include Pages::Base register_tours do tour
' 請求書⼀覧画⾯', '/invoices' do screenshot full: true check 'order[invoices][]', match: :first screenshot ' フッター- 単独', full: true check 'all-checkbox' screenshot ' フッター- 複数', full: true uncheck 'all-checkbox' # ...

テストコード基本はただのCapybaraコードヘルパーメソッドをいくつか作っている tour(view_name, path) pathにvisitする screenshot(state_name, full: bool, sleep:
oat) 現在の画面を(view_name + state_name)で保存する fullなら縦幅を要素に合わせる画面キャプチャ前にsleep秒待つ

キャプチャするメソッド def screenshot(name = nil, wait: 0.5, full: false) #
テキストボックスのキャレットが表示されないようにする page.execute_script "document.activeElement.style.caretColor = 'transparent'" # ページの読み込み待ちと負荷軽減を兼ねて、少し待つ sleep(wait) # 全体をスクリーンショットに撮るために、ブラウザウィンドウをリサイズする resize_to_full if full Capybara::Screenshot.new_saver(Capybara, Capybara.page, false, name ? "#{pagename}_#{name}" # ブラウザウィンドをリサイズしていた場合、元に戻す resize_to_default if full end

どの程度網羅するかコーナーケースを追求しすぎない 1ケースごとに実行がかなり遅くなる実環境に対しては分散実行も負荷・競合リスクになる重要 / 典型的なケースをテストする 1画面で複数の状態をテストする一覧画面では複数項目でパターン網羅できる

一覧画面の例

誤差の許容どの程度、画像の誤差を許容するか小さすぎると誤検知が増える(False Positive) 大きすぎると差異を見逃す(False Negative) False Positiveが多すぎるとつらいブラウザレンダリングで数pxのdiffが出たりする

微妙な誤差

誤差許容の設定 // regconfig.json { "core": { "workingDir": ".reg", "actualDir": "screenshots",
"thresholdPixel": 50, "addIgnore": true, "thresholdRate": 0, "ximgdiff": { "invocationType": "client" } }, // ... }

差分検知時の対応本番/ステージでは意図通りのdiffが出るお知らせの更新など、本番のデータ変更実際のデザイン変更 Slackに通知してチェックするスレッドがついてなければまだ誰も見ていない差分検知時に確認する体制 / フローが重要

Slack通知(再掲)

PRごとのビジュアルテスト表示に使うデータを揃える必要がある created_atなども表示するなら揃える必要がある既存のfeature specとは別にしたほうが扱いやすそう rrrspecで分散実行している画像を集約する必要がある S3に吐いておけば良さそう

コンポーネント単位のテスト全部Vue.js化すればできる…… そう簡単にはできない partial単位で画像を作れないか必要なCSSだけ読み込めるように分けるコンポーネントカタログ的なページをRailsでレンダリングページ全体をrenderしてから必要な要素以外をdisplay: hiddenにする

結局導入してよかった？よかったリファクタで意図しないマージンにリリース前時点で気づけた「意図通りにデザインが変わる」ことを確認できるのも安心できる仕組みを作れば、保守コストは割と安い DOM構造が変わってもほとんど直さずに動く CIにかかる時間は増えるので、うまく妥協する

まとめビジュアルテストにもいろいろある運用環境での差分検査が導入しやすい重要な部分に絞って網羅的に検査するのもあり普通のテストと違う運用が必要 False PositiveとFalse Negativeのバランスを取る検知した差分が意図どおりか確認する体制・フロー

Misocaにおけるビジュアルテストへの取り組み

Misocaにおけるビジュアルテストへの取り組み

More Decks by kokuyouwind

Other Decks in Programming

Featured

Transcript