ランサーズ(Lancers)エンジニアブログ > フロントエンド > フロントエンド定例 > ビジュアルリグレッションツールLoki Storybook書いていて気付くこと フロントエンド定例 2022/7/29

ビジュアルリグレッションツールLoki Storybook書いていて気付くこと フロントエンド定例 2022/7/29

igarashisho|2022年07月29日
フロントエンド

こんにちは、フロントエンドチームの @syo_igarashi です。
今週のフロントエンド定例の内容を記載します。

フロントエンド定例について、以前の記事(ランサーズのフロントエンドチームが取り組んでいること)でお伝えしたのですが、毎週金曜日に開催しており、実際の業務で取り組んでいることや気になった技術情報等をシェアしあう会になっています。

以下、今週の内容です。

ビジュアルリグレッションツールLoki

フロントエンド定例 2022/5/13

上記の定例以前からデザインシステムでreg-suitを使用したビジュアルリグレッションの実行をしていましたがLokiに変更しました。

理由としてはリグレッションのためにAWS S3などのホスティングなしでGitHubに差分があるスクリーンショットをコミットすれば同様にPRで差分検知できるためLokiに変更しました。
GitHubなのでコミット履歴ごとでの差分を追うことも可能なのもいいですね。
GitHub上の画像比較もそんなに悪くないですがreg-suitの方が違いはわかりやすい表示だと思います。

あとはローカルで検証できるのも良い点です。
(reg-suitはCIベースに差分を出してくれていたと思えばあれはあれで良い

使い方

yarn add loki

を実行しインストールします。
yarn loki initで設定ファイルも自動生成されますが
loki.config.jsを設置し内容として

module.exports = {
  configurations: {
    'chrome.laptop': {
      target: 'chrome.app',
      width: 1366,
      height: 768,
      deviceScaleFactor: 1,
      mobile: false,
    },
  },
};

という設定をしました。公式の設定の説明みるとデスクトップにインストールされているChrome実行以外にiOSシミュレータ、Docker、AWS Lambdaなどローカル以外での用途でも組み込みやすそうかなという感じがあって充実した設定だと思いました。

設定後、

yarn loki test

でリグレッションの実行を行います。
初回の差分がないときは.loki/referenceの中に画像ファイルが設置されます。

2回目以降、差分が発生しうるときにリグレッションを実行すると.loki/differenceに差分のファイルが設置されます。

この状態で

yarn loki approve

すると差分があった箇所の画像を.loki/referenceに設置されてGitのファイル変更の差分としてもコミットの対象になるのでコミットしてPRで差分をみるという流れになります。

以前はCI必須なのがありインフラ連携など大変でしたが、LokiはGitHubで完結させるやり方(GitHubに画像置きたくないというのもあるだろうけど)なためお試しとしてもやりやすく思い、デザインシステム以外のプロジェクトでも積極的に入れていきたいと思うツールだと思いました。

ちゃんとStorybook書いていたらちょっとしたマークアップ修正の証跡もリグレッションツールの画像コミットして終わりという未来はみてたりしてます。

Storybook書いていて気付くこと

スタイルの適応確認

Storybookが足りていないプロジェクトにありがち?なこととしてReactで適応されるCSS以外のものが実際のアプリケーションには含まれているのでStorybookのコンポーネント単位でみたときにスタイルが崩れているときがあったりします。

極力、外のCSSでコンポーネントを整えない方がパーツとしては分離してて良いのではないかと思う反面で、
別で共通利用しているCSSもデザインシステム側に持ってくるようにし、globals.cssみたいなどのSass、Reactでも使用可能なものを別だしするのもありなのかも?というのは思いました。

画面遷移・網羅して全てのページを確認できるStoryは1つあった方がいい

表示系の画面の対応してよくあるのが動作確認の証跡のために対象の画面に遷移するまでに色々データを作る工程が大変なのもあるので事前にAPIモック(このデータを生成するのも大変ではあるがデータ消えたときに再度作り直すかよりはモック作ってしまった方が良い)で検証しちゃって画面確認もOKで良いのではと思うときがあります。(これが久しぶりにビジュアルリグレッションに手を出したきっかけ)

1つ網羅したStoryあれば単一のページのStoryにも流用可能なのでAPIモックデータを先に整えてしまうというのも開発フローのうちの1つかもしれません。

画面遷移で辛いもの、react-routerとかrecoil、reduxとかコンポーネント外でラップしてコンポーネント内でhook関数使っているときとかたまにどうラップしてたんだっけかとかなりますね。

 

次回の更新予定は、8/5(金)になります!

前回の定例内容はこちらから確認可能ですのでご興味いただければ下記のリンクから閲覧いただければと思います。

https://engineer.blog.lancers.jp/?s=フロントエンド定例