コンポーネント開発でテストを書くための意識作り
こんにちは、 Gaji-Labo 鈴木です。
React + Storybook でコンポーネント開発をすることが多い話を以前書きました。
そのフローではコンポーネントのテストを書くことも含まれていますが、以前は「テストしたほうが良いって聞くけどやったことない」の状態でした。
どうなったらテストしたことになるのか？テストは具体的にどんないいことがあるのか？
このあたりの納得感を掴むのに少しつまずいたので、なんでテスト書くといいんだろう？と思っていた過去の自分のために書いていきます。
テストってなんで大事？
コンポーネントに変更を加えた際、すべて自力で目視確認するには限界があると思います。
見たつもりが見落としていたり、想定してなかった範囲をそもそもチェックしていなかったり、確認漏れが起きる要因は様々です。
壊れていないかをすべて目視のみで表示確認する場合、コンポーネントの使われている場所が増えたり、コンポーネントそのものが増えればそれだけで膨大な時間がかかります。
そして開発者が自分一人とは限らず、他の人が既存コンポーネントを触る可能性は大いにあります。
影響範囲の考慮漏れにより意図しない変更が出てしまったとき、そもそも気づけなかったり、元々そうだったのかな？という判断でそのままにされる可能性もあります。
もしそれらをカバーするテストが存在していれば、意図していた状態を変えてしまったことに気づけます。
テストを書くのは確認作業の効率化以外にも、他の開発メンバーのためにもなります。
なにをテストしたいかでテスト方法を選択する
なにをテストしたいかによって、テストの書き方や使うツールも変わってきます。
ここではツールの紹介や導入手順の説明はせず、使ってみた所感や使い所について書いていきます。
ツールの概要や導入手順については公式ドキュメント等をご参考ください。
スナップショットテスト
コンポーネントのレンダリング結果のスナップショットを生成し、 UI が意図せず変更されていないか、また、変更をした場合には期待する差分が生じるか、これらを確認するのに有用なツールです。
今となってはメリットを感じていますが当初は、どういう良いことがあるの？としっくりきませんでした。
以下のポイントを抑えたことで、メリットと使い所が分かるようになりました。
- 初回の snapshot は期待した通りのレンダリングになっていれば OK
- 開発していくうちに意図せずコンポーネントに変更を与えてしまった場合、 snapshot テストがコケるので気付ける
- 毎回目視確認できるくらいの小規模ならまだしも、規模が大きくなってくると見落とすリスクが高まる
- 意図しない状態が漫然と広がっていくのを防ぐのに有効
このようなメリットがありますが、 snapshot だけでコンポーネントの状態の全パターンを担保するのは難しい場合もあります。
例えば、あるコンポーネントの状態が props によって複数パターンに変化する場合などです。その場合はスナップショットテスト以外に、ユニットテストをするとよりテストしやすくなります。
ユニットテスト
以下のようなコンポーネントの変化を確かめたい時に、それらのパターンをテストするよう書いています。
- 受け取った props の状態によって
classNameや表示されるべきテキストが変わる - optinal な props が存在している/していない時のレンダリングの違い
- コンポーネントがレンダリングしているデータが期待通りか
スナップショットテストで全体のレンダリングが大きく壊れたりしていないか、意図せず変更されていないかを確認し、ユニットテストで各コンポーネントの振る舞いを確かめることで、安全に開発に取り組むことができます。
テストの使い所・メリットがわかった後は、実際に人のテストコードを見て確認どころを掴んだりしながら、過不足のないテストを書けるように心がけています。
関連リンク
