https://zenn.dev/sum0/articles/9463d16d9d40e2#component-story-format-3.0で記述する
最後に紹介するのは、Storybookからスナップショットを自動生成させることです。 スナップショットテストは、フロントエンドにおいて地位を確立しているテスト手法です。 ここではスナップショットテストの意義については割愛しますが、気になる方はJestのスナップショットテストをご一読ください。
Jestにおけるスナップショットテストの冒頭を引用すると、次のようなことが書いてあります。
スナップショットのテストはUI が予期せず変更されていないかを確かめるのに非常に有用なツールです。
読み取るにスナップショットテストはUI、即ちスタイルを主な対象としたテストです。 ここでStorybookの意義と恩恵を思い出してください。 Storybookはコンポーネントのスタイルを対象としたものです。 これらに相互補完の関係があるのではないか考えるのは自然なことであると思われます。 実際にそうです。 スナップショットテストがコンポーネントの変更を検知した際に、Storybookが提供することでカタログでスタイルの何が変更されたかを確認できます。 これはまさしく相互補完の関係です。 更にStorybookからスナップショットは自動生成できる仕組みが提供されています。 例えばStorybookのアドオンとしてStoryshotsがあります。
このような仕組みをStorybookと合わせて導入することで、より大きなリターンを得られます。 （テスト工数のコスト削減という切り口で捉えてもいいかもしれません）
この節は些か乱暴な議論を振り回しており、それに対してご指摘がありました。
端的に言えばスタイルは、上記の意味でのスナップショットテストでカバーできる範疇ではないということであります。 これは実際正しく、スナップショットテストではインラインスタイルではないCSS手法を採用した際はCSSはモックされるためスタイルの変更検知とまではいきません。 ですので正確には、スナップショットテストはStorybookと正の相互作用があるという程度に留めるのがベターでしょう。 スタイルまでカバーするにはVisual Regression Testの検討を推奨します。 （ご指摘ありがとうございました。この場を借りてお礼申し上げます。）
紹介した3要素は一言で言えば、次のようにまとめられます。 プロジェクトの複雑化を避け、ファイル生成のコストを共通化で抑え、スナップショットテストと絡めてリターンを得る。 またStorybookはコンポーネント指向におけるスタイルに関して強固なフィードバックループを作るという点で、アプリケーション開発の指導原理に沿っていると私は考えています。 無論Storybookは時に、スタイルというメンテナビリティの低い対象と向き合うため牙を剥くかと思います。 実際私も、困ったことに何度も直面しましたし、今後も困ることがあると思います。 ですが、Storybookがスタイルという魔物に真正面から向き合う姿勢は尊敬されるべきものであると思います。
以下は蛇足ですが、検討すると楽しげなものを紹介します。
Storybookの記述は幾度かバージョンアップし、執筆当時ではバージョン3まで出ています。 ガイドやチュートリアルではバージョン2の記法がありますが、個人的に現状はバージョン3が最も自然な書き方に見えます。 下記のガイドを是非一読し、バージョン3スタイルでStorybookを記述することを推奨します。
こちらはフロントエンドの"ちょうどいい"自動テストのはじめかたの「"Pure" View Componentを作っておく」にて紹介された手法です。 実はStorybookはロジック面と相性が悪く、適宜モックが必要となります。 実際私はRecoilを呼び出すコンポーネントを実装時にStorybookが壊れてしまいました。 ですが、Storybookの主眼はあくまでスタイルです。 スタイルだけを持った、ロジックを持たないコンポーネントを作ってしまえば良いのではないかというアイデアがPure View Componentです。 （私はこの考え方に触れた時まさに、目から鱗でした） 他にも面白く、興味深いフロントエンドに関わるテスト指針が記載されております。