こんにちは、リードエンジニアの @dachi_023 です。4ヶ月前に Storybookを利用した開発フローの設計 という記事を書いてから今も引き続き上手くやれてますよ、という話とテスト運用についても改善を入れたことなどについて書きます。プロダクトコード外の運用ができていないなと感じる方向けの記事になればいいなと思っています。
運用し続けることが大事
テストがあることで仕様を担保しながら安心して実装することができます。コンポーネントカタログがあることでコンポーネントのドキュメントを簡単に生成でき、また UI に関する話をする際に実際に動くものとして提示できる材料になります。
といったようにテストもコンポーネントカタログも特定のシーンで大きく効果を発揮するものですが、導入しただけでは意味がなく運用し続けるための工夫が必要です。例えば特定のケースが担保できていないテストや実装時にコンポーネントカタログに追加し忘れたコンポーネントがある状態が放置され続けていればその効果も薄まりますし、それを解消する方向に導かなければ足りない箇所がどんどんと増えていくかもしれません。
これらを達成するために意図通りの仕様で動作しているかを検査する仕組みを作ったり、日常的に取り組めるよう開発フローの一部として組み込んだりすることが重要だと考えています。入れたら勝手に運用が回っていく、ということはそうそうないと思います。
コンポーネント単位で PR を作る
(冒頭に貼り付けた記事 に経緯などが書かれていますので是非読んでみてください)
私達のチームではいきなりページ全体を実装する、といった方法は取らずコンポーネントごとに実装しています。ページごと丸っと誰かをアサインして開発していくといったこともできなくはないですがページによって実装難易度も大きく変わってきますし、何日もかかったりすると他の作業をブロックしたり小さくリリースすることが難しくなります。また、コード量や対象範囲が大きくなることでレビュー時にレビュアー・レビュイーの双方に負担をかけかねません。
そういったことを回避するためにまずはページ内で新規実装する必要があるコンポーネントの実装を GitHub Issue 化して個別に対応 → Storybook に追加・レビュー → ひと通り揃ったところでページを組み立て、というフローにしています。
上記を実践するためのツールとして Storybook を採用しています。コンポーネントを個別に実装していった際の「実際に動く場所がなくてレビューできない」という問題を解消するために利用しています。これによって小さく実装し、小さくリリースしていくことができています。また、コンポーネントを1つずつ PR にしていくことでレビュー時の観点が絞られるので (コンポーネントとしての設計・コード・UI の挙動) 指摘や修正が広範囲にならずに済みますし、ページを組み立てた際のレビューもページとしての仕様が担保できているか、を中心にレビューすれば良くなります。
非同期コミュニケーションの回数が増えると作業が中断されたりボールが返ってくるまでに時間がかかったりするので分解できるものは分解して、というのが基本方針です。
テストケースの考慮不足に気づく
テストに関しても同様で「開発フローに組み込む」「レビューで活用する」といった考えでやっています。これを実現するためにチームでは Codecov を利用しています。テストは実装されているか、どのケースを考慮してテストを書いたか、テスト済み以外のコードでテストすべき点はないか、などを見つけるために有効です。
網羅率に関するルールなどは特に明記してありませんが「アプリケーション全体としてある程度書けていること」をチェックするために全体の網羅率が 90% を切った時に CI が赤くなるよう設定しています *1。
機械的に判定 (カバレッジが担保できているかチェック) するだけでなく「仕様に対して適切なテストができているか」をレビューするところまでをセットとして捉えています。
まとめ
本記事で挙げたようなツールの運用がストップしてしまうのは「プロダクト開発に必須でない (= プロダクションで動かない)」という意識なのではないかと思っています。
短期的に考えたらあまり効果的ではないかもしれないです。しかし、チームとして過去のコードを活かしながら何年も開発し続けるためには重要な要素です。入れるだけではなく、しっかりと活用するところまでイメージしながら開発していきましょう。
*1:厳密に設定しているわけではなく、都度様子見ながら運用しています
