hacomono TECH BLOG

フィットネスクラブ・スクールなど施設・店舗のための会員管理・予約・決済システム「hacomono」 開発チームの技術ブログ

がんばらないフロントエンドのテストを考える (UI-test 編)

こんにちは!開発チームの山中です!

hacomonoでは、ユーザサイト・管理者サイトのそれぞれを、Nuxt.js で開発しております。

私がジョインした時点では、どちらにもテストコードが実装されておらず、 私の最初のミッションは、これらの品質を担保するための仕組みづくりでした。

今回は、表題の通り、弊社でのフロントエンドのテストについて、どのように実施しているか、説明していきます。

情報量が多いので、今後シリーズ化していくと思います

TL;DR

3行でまとめ

  • Jestの仮想DOMを使用するテストは大変なのでやらず、関数入出力のテストのみを担保する。
  • テストケースをStorybookで作る
  • 作ったStorybookを、Chromatic上でUI-Test / ビジュアルリグレッションテストする。

フロントエンドのテストが重い問題

さて、フロントエンドのテストというと、どうやっても以下の問題にぶち当たると思います

  • 実装のためのコード量が多い
  • 仮想DOMでのテスト実装が大変
  • 変化が早いため、修正頻度が多い

1つずつ考えていきます。

実装のためのコード量が多い

シンプルな話だと思います。

弊社の製品では、ほとんどのページが動的で、テストケースは多岐に渡ります。 ユーザサイトの新規登録画面を例に考えると、以下の条件で見た目や導線が変化します

  • viewport (PC, モバイル)
  • ブランドごとのカスタムテーマ
  • 会員情報の入力欄設定
  • アンケート項目設定

これらの条件ごとに、DOMの構造や、入力欄への入力のシナリオ等を記述していくのは、かなり手間であることは、容易に想像できると思います。

f:id:hacomono-tech:20211105163417p:plain
デフォルトの会員登録ページ(PC)

f:id:hacomono-tech:20211105163513p:plain
デフォルトの会員登録ページ(モバイル)

仮想DOMでのテスト実装が大変

フロントエンドでのテスト実装といえば、メジャーどころを挙げると jest がトップに上がってくると思います。

jestjs.io

仮想DOMでのテストというと、「ボタンをクリックする」「入力欄を選んで入力する」等の操作を全てJavascriptで記述していき、 最終的なDOM構造をテストします。

個人的な所感ではありますが、これが正直辛く感じました。 DOMの見た目をテストしたいのだから、プレビューを見ながらテストを書けないのは苦痛です。

前述するような前提条件の多さによる見た目の違いを、DOMの構造だけを見ながらテストを実装するのはあまりにも無理があります。

変化が早いため、修正頻度が多い

弊社では、大きなアップデートを2ヶ月に1度行っています。

このアップデートでは、主に管理画面での機能追加と、対応するユーザサイトの画面追加や変更を伴います。 前述してきた手間の多さや難易度の高さを、このスピードに乗せるのは無理と判断しました。

弊社のフロントエンドのテスト戦略

前述する課題は、大雑把に考えれば、前述する課題は以下に置き換えられます

  • 見た目を把握せずに記述するのが辛い
  • 前提条件による見た目の変化が多い
  • なるべく簡単に書きたい

そこで、弊社では以下のようにテスト戦略を設定しました。

  • 前提条件ごとに、コンポーネントの見た目を Storybook で実装する
  • 実装した Storybook を使って、Chromatic 上でテストする
  • 関数の入出力テストのみを jest によって実装する

Storybook とは

ReactやVue等のフレームワークで広く利用されるUIテストモジュールです。 個別のUIコンポーネントをブラウザ上で描画し、UIの見た目や操作をテストすることができます。

storybook.js.org

f:id:hacomono-tech:20211105162811p:plain
ボタンを表示するStoryのサンプル

Chromatic とは

Storybookの拡張機能として利用できるwebアプリケーションです。 CIでStorybookをビルドし、共有することができます。 また、過去に実施したビルドとの差分を検知し、差分が発生したStoryを比較することができます。

www.chromatic.com

一つ前のビルドと差分が出た際、「変更前後のStory」「スクリーンショット」「DOM構造」の3つの差分を確認し、 その変更が妥当かどうかをレビューします。

f:id:hacomono-tech:20211105162840p:plain
ビジュアルリグレッションテストの例

Storybook をテストケースとして利用する

基本的に、正常入力に対して正常な見た目・DOMの出力が得られるようなStoryを作成します。 これをChromatic上で管理することで、Unit Testとビジュアルリグレッションテストを同時に実施する狙いです。

メリット・デメリット

このテスト戦略では、以下のメリットとデメリットがあるように感じました。

メリット

  • UnitTestとビジュアルリグレッションテストを同時に行えるため、手間が少ない
  • 見た目を気にしながら実装できる

欠点

  • 前提条件のデータを用意する所で手間が解消されていない
  • Chromaticのプラン成約により、月の利用可能数上限がある

おわりに

今回は、弊社が実践しているフロントエンドのテスト戦略について、紹介いたしました。

まだ課題が多く、紹介しきれていない事も多いので、このテーマについては、シリーズ物として、 今後も投稿していきたいと思います。