Storybookの旨味をしゃぶり尽くす
Storybookを取り入れたワークフローで開発を行ったところ、Storybookは単なるスタイルガイドツールではなく、ビジュアル実装のためのインフラであることを実感しました。
三度どころじゃなくおいしいなと感じているので、導入がまだならシュッと導入してしゃぶりつくして欲しいなと思いました。開発がある程度進んでからでも小さく導入できるので、予め考えておく必要のあることはあまり無いと思います。三度おいしいスライドと内容が被っていますが、おいしいものはおいしいので何度でもおいしいことを主張していきたいという思いです。
TL;DR
minodisk/glaphというリポジトリを例にとり、Storybookを使ったワークフローの中で生まれる旨味を紹介します。
- ストーリーを追加してビジュアルを実装する
- ストーリーを追加してバグを修正する
- ストーリーを元にVisual Regression Testする
- ストーリーを元にカバレッジを測定する
- ストーリーでコミュニケーションする
1. ストーリーを追加してビジュアルを実装する
ストーリーを追加しつつビジュアルの実装を行います。ストーリーを元に実装することで、実装しなければならない状況を作り出すためのオペレーションをすることなく、実装に集中することができます。
また、追加したストーリーは後に続くVisual Regression Testによってテストケースそのものになります。考えうるパターンをストーリーに書き下しつつ実装することで、実装漏れが減り、仕様の不明点を洗い出すことにも繋がります。単純な類似ケースを増やす目的においては、Table Driven TestならぬTable Driven Storyするとストーリーを追加するコストが少ないのでおすすめです。
2. ストーリーを追加してバグを修正する
レイアウト崩れやデザインの再現不足などの、ビジュアル上のバグが起きたとします。そんな時は、バグが起きるケースのストーリーを追加した後、実装を直します。繰り返しになりますが、追加したストーリーは後に続くVisual Regression Testによってテストケースそのものになります。
3. ストーリーを元にVisual Regression Testする
Regression Testとは実装を追加・変更した際に、デグレーションをしていないかを確認するためのテストです。Storybookに追加したストーリーのスクリーンショットを撮り、追加・変更前のスクリーンショットから意図しない変更が発生していないかを確認することでデグレーションを防ぎます。
どうやってやるの？
minodisk/glaphではCIで次のようなフローを実行しています。
- Quramy/zisuiでStorybookのスクリーンショットを撮る
- reg-viz/reg-suitでブランチ分岐点のスクリーンショットと現在のスクリーンショットを比較し差分を検出しGCSに保存、GitHubのPRにインテグレート
- ビジュアルのデグレーションが判明したら実装を修正
使うツール
もっと詳しく
4. ストーリーを元にカバレッジを測定する
前提として、カバレッジは単に実装コードがテストによってどの程度網羅されているか表しているだけで、テストのクオリティやテストケースが十分であるかを表しているわけではないことを理解しておく必要があります。つまり、カバレッジを測定することで分かることは、テストで網羅されていないコードが存在しているという事実だけです。
Visual Regression Testを行っている前提では、ストーリーのレンダリングために通ったコードは最低限テストされていると考えて良いと考えています。テストのクオリティを上げるためには、ドメインに沿ったケースのストーリーを増やしていくことでテストケースを充実させていく必要があります。
どうやってやるの？
Storyshotsを起動するテストをJestのテスト対象に追加するだけです。後は以下のコマンドでシュッとカバレッジを測定できます。
jest --coverage --updateSnapshotStoryshotsで網羅されないコードはどうするか
カバレッジの分析結果を見て網羅されていないコードが見つかり、かつそのコードがビジュアルに関係のあるコードならば、そのコードを網羅するためのストーリーを追加すると良いでしょう。
イベントハンドラなどから呼ばれるコードが網羅されておらず、かつそのイベントをきっかけにビジュアルが変化するのであれば、ビジュアルを変化させるコードをメソッドに切り出すなどして、そのメソッドをコールするストーリーを追加すると良いでしょう。
ビジュアルに関与しないコードが網羅されていないのであれば、もはやStorybookの出る幕ではないです。このフローで行っているのは、あくまでもビジュアルに対するテストなので、ビジュアルに関与しないコードに対してはStoryshotsによる網羅の有無によらず普通にテストを書く必要があります。
使うツール
5. ストーリーでコミュニケーションする
まずはビルドしたStorybookをチームメンバーが閲覧可能な場所に公開します。公開先はGitHub Pagesでもよいし、S3でもGCSでもよいです。
ケース別にストーリーを用意していると、言及したい状況を説明することなく、URLを共有するだけで特定の状況を指し示すことができます。素早く正確にコンテキストを共有できるので、コミュニケーションコストは激減します。
Storybookはフレームワークの垣根を越えた
もともとReact用のツールだったこともあって、ビューフレームワーク前提のアプリケーション開発の文脈で取り上がられることが多い気がするStorybookですが、ReactやVue.jsなどのビューフレームワークを使わず、生DOMを返すような場合にも有用です。
実際に、minodisk/glaphは前述のようなビューフレームワークを使わないCanvasにWebGLでグラフを描くライブラリですが、この記事で紹介したワークフローで開発している。このリポジトリにはDOMツリーはおろか <canvas> しか返していないストーリーもありますが、 <canvas>へのDraw Call後のレンダリングに対してもVisual Regression Testがワークしています。
最後に伝えたい大切なこと
このようなワークフローでビジュアルの実装をしているFOLIOという会社があるらしいです。
明日23日目は、今回取り上げた reg-suit や zisui をメンテしているQuramyさんです。
（この記事なぜか緑のアイコンだらけになったな 🤔）
