Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
20230511 Storybookを軸としたコンポーネント管理と自動テスト戦略
Search
shozo koga
May 11, 2023
Technology
0
720
20230511 Storybookを軸としたコンポーネント管理と自動テスト戦略
2023/05/11(木) に開催された「スタフェス Meetup #3 - PJの技術的取り組み公開」にて登壇しました
shozo koga
May 11, 2023
Tweet
Share
More Decks by shozo koga
See All by shozo koga
Looker StudioとSnowflakeでプロダクトチームのダッシュボードを作る取り組み
koga1020
0
630
20230311 最近のElixir動向まとめ
koga1020
0
700
【Elixir】Dataloaderを導入してGraphQLのN+1問題を解消する
koga1020
1
470
20221108 WEB+DB PRESS Vol.131「はじめてのElixir」特集記念イベント
koga1020
1
230
fukuoka.exの思い出話とこれからを考える
koga1020
1
180
Ectoの全体感をまとめてみる
koga1020
0
510
Phoenix.PubSubの紹介と活用を考える
koga1020
0
470
EDI#1 発足LT会
koga1020
0
63
Web開発 × Elixir
koga1020
0
260
Other Decks in Technology
See All in Technology
AI導入の理想と現実~コストと浸透〜
oprstchn
0
190
AIの全社活用を推進するための安全なレールを敷いた話
shoheimitani
2
380
自律的なスケーリング手法FASTにおけるVPoEとしてのアカウンタビリティ / dev-productivity-con-2025
yoshikiiida
1
14k
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
4
520
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
7
5.1k
AWS認定を取る中で感じたこと
siromi
1
170
Backlog ユーザー棚卸しRTA、多分これが一番早いと思います
__allllllllez__
1
130
Tech-Verse 2025 Keynote
lycorptech_jp
PRO
0
1.7k
「クラウドコスト絶対削減」を支える技術—FinOpsを超えた徹底的なクラウドコスト削減の実践論
delta_tech
4
130
改めてAWS WAFを振り返る~業務で使うためのポイント~
masakiokuda
2
230
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
430
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
330
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
810
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Into the Great Unknown - MozCon
thekraken
39
1.9k
Speed Design
sergeychernyshev
32
1k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
How to train your dragon (web standard)
notwaldorf
94
6.1k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
950
Agile that works and the tools we love
rasmusluckow
329
21k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Transcript
Storybook を軸としたコンポーネント管理と 自動テスト戦略 2023.05.11@ スタフェス Meetup #3 - PJ の技術的取り組み公開
@koga1020_
About Me @koga1020_ @koga1020 koga1020.com 古賀 祥造(koga1020) 株式会社スターフェスティバル ソフトウェアエンジニア 2023.01に入社
/ 十五夜プロジェクト TechPM 福岡在住のリモートワーカー👨💻 FindyのChatGPTエンジニアキャリアまとめ 「ソフトウェア界の鬼殺し」「オシャレIT男子」 2
お品書き 📝 担当しているプロダクトとチーム体制 フロントエンド領域での取り組み Atomic Designの良し悪し、課題感 Storybookの活用 開発スタイル テストの方針 ドキュメンテーション
3
プロダクトとチーム体制 4
"ごちクルBusiness" というプロダクトを開発しています 従業員のアカウント管理、請求管理など、法人さまがより便利にごちクルをご利用いただけるようにするサービス 5
チーム体制 「プロダクトファースト」を掲げ、プロダクトごとに開発チームが存在する 各チームが裁量を持って、意思決定しながら開発を進めている 参考:「プロダクトファースト」へ大きく舵を切って約2年、スタフェスの現在地は?CTO x CPOが対談 KAGUYA プロジェクト PJ 横断
KAGUYA ⼗五夜 デザイナーチーム プロダクト チーム プロダクト チーム KAGUYA KM ごちクル Business PJ リーダー sotarok エンジニア PDM オペレーション 6
開発スタイル 全員リモートワークのため、対面でのコミュニケーションは無し🏠👨💻 PdM主導で要件を固めてConfluence, Figmaを整備 エンジニアと技術的な観点も踏まえて要件を詰めていく 余談:figma, confluenceのslack通知をチーム皆で設定して非同期コミュニケーションが活性化しました👍 slackで「このコメント見てください!」のコストをなくす 7
プロダクトの構成・技術スタック 8
フロントエンドの構成 ごちクルBusiness Frontend[Next.js] Backend[NestJS] Client BFF Server trpc Endpoint trpc
call API 9
フロントエンドの構成 ごちクルBusiness Frontend[Next.js] Backend[NestJS] Client BFF Server trpc Endpoint trpc
call API 10
Atomic Designでやっています おなじみAtomic Designです Pagesの扱いをNext.jsの pages ディレクトリとし、それ以外は components/ で管理しています 11
./ └── src/ ├── pages/ │ └── user/ │ └── index.tsx ・・・ pages に相当するコンポーネン └── components/ ├── atoms/ │ └── Label/ │ ├── index.tsx ・・・ Barrel file │ ├── Label.tsx ・・・ 実装ファイル │ └── Label.stories.tsx ・・・ story ├── molecules ├── organisms ├── templates └── pages ・・・ storybook 格納用
所感 atoms, moleculesはめちゃくちゃしっくりきています👏 きちんとstorybookを運用することで、再利用可能なコンポーネント開発ができています 「🧑💻 別画面でも使うTableコンポーネント作っといたで〜」 「👩💻 すでにそのUIならListコンポーネントがありますよ〜」 Figmaを眺めることで、共通の部品が見えてくる Table,
Card, Form, Modal, …etc templates、organismsも今の規模感だと違和感なし pagesの実装は今後のスケール時に要注意⚠️ 外部API呼び出しなど、ドメインロジックをpages内で実装している現状 複雑な画面だとpagesが肥大化してきているのも事実 12
機能単位でのディレクトリ構成も検討したが採用せず pagesの肥大化に対して打ち手を検討した Bulletproof Reactで紹介されているような、機能ごとに分割する構成も考えた 参考: 私の推しフロントエンドディレクトリ構成と気をつけたいポイント 今の規模感であれば、Pages内にロジックが書かれていても追えるボリュームでは?という結論に至った 機能単位に分けたことにより、実はatoms, molecules, organisms
など再利用可能なものにできるものを 個別に実装してしまう可能性を危惧した プロジェクトで再利用可能なコンポーネントを育てていく方を優先することとした 今後やたら複雑なページが出てくるなどした場合には再考の余地あり 13
再利用可能なコンポーネントを育てるには 🌱 storybookを活用しまくる!! ただ、storyの実装はコストがかかるのは事実 storybookを腐らせずに、かけたコストに対してリターンを最大限享受するためにどうするか🤔 14
Storybook の活用と自動テスト戦略 15
Storybook活用のポイント ① Storybook 駆動で開発する ② story をテストに再利用する ③ story が壊れていないことを担保する
④ 開発時のドキュメンテーションとして活用する 16
① storybook駆動で開発する 実装を書いた後にstoryを用意するのではなく、まず実装が空の状態からstoryを用意する ページに組み込む前からコンポーネントのレンダリング結果を確認する環境としてstorybookを利用する hygenを活用して、実装ファイルとストーリーファイルがコマンド一発で出来る環境を整備しています🚀 Component Story Format3(CSF3.0)だとだいぶ書きやすいです Storybook7からCSF3がデフォルトとのこと https://storybook.js.org/blog/storybook-csf3-is-here/
17
Storybook活用のポイント ① Storybook 駆動で開発する✅ ② story をテストに再利用する ③ story が壊れていないことを担保する
④ 開発時のドキュメンテーションとして活用する 18
② storyをテストに再利用する 単純なコンポーネントであれば別途specを用意せず、storybookのビルドが通るかで担保する specを書きたい!となったらそれはなんらかのロジックを伴うもののはず 別途 hooks などに関数として切り出し、その切り出した関数の単体テストを書けば十分なはず specを書く場合には、storyを再利用して書くべし 参考: Storybook
CSF3.0で登録したStoryをJestで再利用する clickやテキスト入力など、イベントが必要なテストはInteraction testとして実装する https://storybook.js.org/docs/react/writing-tests/interaction-testing 後述するChromaticではこのInteraction testが通らない場合はエラーとして検出できます🎉 19
② storyをテストに再利用する https://storybook.js.org/docs/react/writing-tests/interaction-testing 20
Storybook活用のポイント ① Storybook 駆動で開発する✅ ② story をテストに再利用する✅ ③ story が壊れていないことを担保する
④ 開発時のドキュメンテーションとして活用する 21
③ storyが壊れていないことを担保する CIでstorybookのbuildが通ることを常に担保すべし CIで見ておかないと気づいたらビルドが通らないstoryが出来ているなんてことも 割れ窓理論。割れた窓を作らないように頑張りましょう🪟💥 Chromatic が超便利 storybookのホスティングサービス。VRT(Visual Regression Test)やUIレビューが可能
前述したinteraction testも実行され、動作の担保ができる 無料枠もあり気軽にお試しできます note: 気をつけないとdependabotやrenovateでガンガン回るのでお気をつけを Turbosnap という差分ビルドの仕組みもあります StorybookのTest runnerでもビルドおよびinteraction testが通ることを担保できます 22
Storybook活用のポイント ① Storybook 駆動で開発する✅ ② story をテストに再利用する✅ ③ story が壊れていないことを担保する✅
④ 開発時のドキュメンテーションとして活用する 23
④ 開発時のドキュメンテーションとして活用する 特定のコンポーネント・storyと紐づかないドキュメントも記述できる mdx#writing-unattached-documentation Storyのレンダリング結果やTailwindCSSの設定などを参照してドキュメントが書けるので、 READMEのようなドキュメントよりコードに近い状態で管理できる 参照すべきドキュメントをstorybookに寄せ、プロダクトコードと同じく保守すべき対象であるという意識づけを行う 誰も見ない、使わないものは腐りゆく 🙈 24
④ 開発時のドキュメンテーションとして活用する 例. カラーのガイドライン。Component のstory と独立したセクションを設けてドキュメントを用意できる 25
④ 開発時のドキュメンテーションとして活用する addon-designsを入れるとstorybook上にFigmaを埋め込むことができる デザインとの齟齬を確認したり、storyを見てるときにパッとfigmaに移動できて便利 26
Storybook活用のポイント ① Storybook 駆動で開発する✅ ② story をテストに再利用する✅ ③ story が壊れていないことを担保する✅
④ 開発時のドキュメンテーションとして活用する✅ 27
WEB+DB PRESS vol.134に掲載されてます 28
まとめ 弊チームの開発スタイル PJリーダー、エンジニア、PdMがいて、スクラムをぐるぐる回している Slack, Figma, Confluenceで非同期コミュニケーションを中心にモリモリ開発 フロントエンド 長い時間軸でプロダクトを育て続けられるコンポーネント管理を目指す コストとリターンのバランスをとりつつstorybookの活用を狙う 割れ窓に気をつけつつ、Chromatic、CIを活用してStorybookを絶対に腐らせない強い気持ち