StoryBook + reg-suit で VRT を構築してみた (1/2)

n-ozawan

皆さん、こんにちは。技術開発グループのn-ozawanです。
12月の師走は、師(僧侶)が仏事で忙しく走り回ることが語源と言われますが、実はこれは「しわす」を当て字にしただけで、本当の語源は古すぎて分からないそうです。

本題です。
ReactやAngularなどのSPA開発では、ボタンなどをコンポーネントで部品化して画面を実装します。コンポーネントを修正することで、そのコンポーネントを使っている別のコンポーネントがデザイン崩れを起こし、これが障害となるケースがあります。今回は画面のリグレッションテストを行ってくれるツールとしてreg-suitを紹介します。

VRT (Visual Regression Testing)

概要

ReactやAngularなどのSPA開発では、ボタンやラベルなどの各画面で良く使うものをコンポーネントで部品化します。また、例えば画面のサイドメニューやヘッダーなどもコンポーネントで作成することもあります。SPAはそういったコンポーネントの集まりで画面を開発します。

フロントエンドを開発しているとよくあるのが、コンポーネントを修正することにより、想定していない画面でデザイン崩れなどのデグレが発生することです。コンポーネントを修正したら、そのコンポーネントを利用している全ての画面を確認する必要があるのですが、それを目視で行うのは手間です。

VRTはコンポーネントの修正前と修正後で、全ての画面をキャプチャして、その差分を比較することにより、意図せぬ変更が行われていないかテストする手法です。

StoryBook

StoryBookはコンポーネントをカタログ化するツールです。StoryBook自体はVRTの機能はありませんが、この後説明するreg-suitで利用します。StoryBookでカタログ化するにはコンポーネントとは別にコードを実装します。以下はボタンをStoryBookでカタログ化したソースコードです。

import type { ComponentStoryObj, Meta } from "@storybook/react"

import { Button } from "."

const meta: Meta = {
  title: "Atoms/Button",
  component: Button,
}
export default meta

export const Primary: ComponentStoryObj<typeof Button> = {
  args: {
    kind: "primary",
  },
  render: args => <Button {...args}>テキスト</Button>,
}

// 以下省略

本稿ではソースコードへの説明は省きます。StoryBookのコードを実装することにより、上記のようにコンポーネントを見ることが出来ます。

大きなシステムを開発すると、コンポーネントの数は100を超えることがあります。そうなってくるとどのコンポーネントを使えばいいのか分からなくなります。また、使うコンポーネントが分かったとしても、どのように使えばいいのか、どういう感じで表示されるのか、ソースコード見てもイメージが湧きません。そのような時にStoryBookは役に立ちます。

reg-suit

reg-suitは画像を比較してその差分を表示してくれるツールです。

reg-suit自身は単に画像を比較するだけのツールですが、提供されているプラグインを組み合わせることにより、VRTとして強力なツールとなります。

以下のイメージ図は公式サイトより転載した画像です。git pushをトリガーにStoryBookの画像をキャプチャします。S3にアップ済みの過去のキャプチャ画像と比較して、その差分結果をS3にアップロードします。このアップロードした差分結果は、次の画像比較にも使われます。また、その差分結果をPR (Pull Request) へコメントします。

開発者は自身が作成したPRにVRTの結果がコメントとして残るため、自身の修正が意図しないデザイン変更となっていないか確認することが出来ます。

おわりに

コンポーネントが増えれば増えるほど、そのリグレッションテストの負荷が増大します。VRTはそのような負荷を解消する1つの手段と言えます。StoryBook + reg-suitの構築手順は次回お話しします。

ではまた。

Recommendおすすめブログ