テスト優先度をあげたくなる実話 - フロントエンド版 -

Storybook・テストに関して「メンテナンス工数に見合うだけのメリットがあるか？」という議論を、経験したことはないでしょうか。フロントエンドは、とにかく動くものを作ることが優先され、Storybook・テストが二の次になっている現場も少なくないと思います。

限りある工数を割きチームで取り組むものですから、導入するためには「どういったメリットがあるのか？」という具体的な例をチームに示す必要があります。これは今年、筆者が体験した実メリットのお話です。導入を躊躇している現場にむけ、参考になればと思い書きました。

【Storybook】不要な Global CSS を削除できた

きちんとコンポーネント設計され、コンポーネントに閉じた指定をしていたとしても、どこかに必ず Global な CSS があると思います。何かしらの資材を受け継ぎ立ち上げたプロジェクトに関しては、Global な CSS を段階的にコンポーネント化するアプローチも少なくないはずです。

こういったアプローチをとる場合、Global なセレクタが使用されているのか否か、判断するのが難しいことがあります。この様なシーンで活きたのが、reg-suit + storycap による VRT（Visual Regression Testing）です。全てのコンポーネントで Story を登録していたことが功を奏しました。

• Global なセレクタを消す
• VRT を回す
• 影響がないことを確認

ということが出来たため、ためらう事なく不要な CSS を削除することが出来ました。CSS は脆さとともに「影響範囲の特定が難しい」という課題がありますが、Story をコミットしておくと、CSS のリファクタに対して自信を持つことができます。

【Storybook】デザインシステム醸成の一助となった

先述のとおり「影響範囲の特定が難しい」事が普通なので、CSS のリファクタに対しては誰もが保守的です。未だに、影響範囲をカプセル化することが第一優先事項となっています。

UI デザインはブランディング変異に伴い、常に変わり続けるものだと筆者は思います。どんなに綺麗にデザインされていても、流行推移とともに陳腐化し、誰にも防ぐことは出来ません。

• デザイナー「これまでの成果物は、新しいガイドラインに沿っていないので変更したいです！」
• ディレクター「影響範囲がわからないので、これまでの物に手を加えたくないですね…」
• デザイナー・ディレクター「（…工数大きそうだし、我慢するしかないかな…）」
• わたし「影響範囲は、すぐに特定できますね。N 件の画面で影響が出て、比較画像がこちらになります」

というやりとりが最近ありました。「何を使って CSS を書くか」という戦術よりも「どうやって影響範囲を特定し・継続的にリファクタ可能な体制を作るか」という戦略の方が、よっぽど重要なことだと、この時実感することができました。

過去、影響範囲を特定する事が難しいという全く同じ理由で「つぎたし実装」を悔しい想いでやり過ごした身として、この体験は忘れられないものになりました。

【Jest】自分が実装した箇所を、メンバーがリファクタした

テストを書くモチベーションとして一般点で、共感者の多い話だと思います。リグレッションテストがあることで、自信をもってリファクタを行うことができます。ある日「既存の機能を壊さず、一部機能だけを抜き出し汎用化したい」という相談がメンバーからありました。

• メンバー「ここの機能に依存したテストって、どこかに書いてましたっけ？」
• わたし「こことここで、結合テスト書いてるよ」
• メンバー「では問題なさそう、リファクタ着手していきますね！」

こんなやりとりがあったので、テストをきちんと書いていた自分に内心ほっとしました。Testing library を用いたコンポーネント間の結合テストは、こういったリグレッションテストの目的で役に立つことが多いです。

わたしもメンバーも、いつかこのプロジェクトから離れる日が来るかもしれません。そうなった時、後継者に自信をもって引き継ぐことができます。リファクタしやすく健全なコードは、バトンリレーみたいですね。

【Jest】要件・実装の考慮漏れに気づけた

きっちり確定仕様を確認しながら実装する現場があれば、ざっくり要件だけで進む現場もあります（開発体制や事業フェーズの話になるので、どちらがどうという話はここではしません）

前者の場合、TDD や BDD の様なアプローチで着実に進める事ができるので、テストも比較的書きやすいのではないでしょうか。

筆者としては後者の「ざっくり要件」だけでも、テストを書くことをお勧めしたいです。API と接続するコンポーネントの場合、とくに「異常系」の考察に役立ちます。

• API を叩く前にバリデーションは必要だっけ？
• その時、エラーはどう表示してたっけ？
• API からエラーが返ってきたとき、どんな表示だっけ？
• API から返ってくるエラーって、本当にこれだけで十分だっけ？

少なくともこれだけの仕様確認が必要になりますし、おのずと書くべきテストも見えてきます。この段階で「ざっくり要件」だけでは不明瞭で、エスカレーションすべき考慮漏れを共有することができます。

まとめ

テストは自信をもって進めることはもちろん、将来のリファクタに備えるために必要です。いまから作るものはいつか必ず陳腐化する前提で、どの様に備えておけばよいか、考える機会にもなると思います。

「取り組んでみたいが、時間に余裕がない…」という制約がついてまわりますが、そこはツールに頼るのもひとつの手だと思います。筆者は Next.js 製のアプリケーションを作る事が多いですが、雛形生成ツールを導入したことが、チーム全員無理なく完遂できた要因のひとつだと考えています。

便利なツールを組み合わせ、よりよい開発体制を作っていきたいですね。