React Component テストを書くための考え方

こんにちは、白石です。

React をはじめたと共にテストを書くようになり早数ヶ月が経ちました。お休みの期間にふと振り返ってみたところ、昨年は色々と先輩方に教えていただきながらも、初めの頃に「さて、どのように書くべきかな...」と悩んだことが多々あったように思います。

そんな中、今回はテストの書き方について説明して下さっている素晴らしい記事¹と出会いましたので、一つの考え方として参考にさせていただきつつ、自分なりに要点をまとめておきたいと思います。 テストコードもさることながら、書くに至るまでの考え方を順序立てて書いて下さっているのは、大変ありがたく、感謝しかありません（-人-）

結論

テストに必要な考え方、テスト範囲、テストするコンポーネントの順序が大切

考え方

• 全てのコンポーネントをテストする必要はない
• テストカバレッジの目標となるパーセンテージを守り、必要のないテストを書くのを避け、主となるコンポーネントの詳細度と信頼性を失わないようにする
• そのためには、最小単位のコンポーネントの動作を担保する。つまるところ、それらの組み合わせで構成されているコンポーネントのテストは難しくならない

テストサイクル

複雑でないものから、複雑なものへ向かってテストしていく。 テスト過程で、単体コンポーネントに分離できそうなものは分離する。

• 独立している単一コンポーネントのテスト
• 補助コンポーネント(俗にutilディレクトリ)
• 独立すべきコンポーネントがある場合は、分離を考える

テスト範囲

下記はテストしないものとする。

• 外部ライブラリのテスト
• 定数
• インラインスタイル
• 既にテスト済みのコンポーネント（import先でテスト済みであったりするもの）

順序

• Snapshotテスト
• propsのテスト
• data(props等）の型チェック
• eventのテスト
• 条件や状態変化前後（domへのclass付け外し等）のテスト

所感

参考サイト¹より、自分なりに要点をまとめて紹介させていただきました。 例では、具体的なプロジェクトファイルを用意して下さっており、その構成に沿って「どのような考えで、どのような順序でテストするべきか」を述べて下さっています。なので、より実践的に学ぶことができました。

Main instructions for component testing の章では、具体的にコードと言葉を交えての説明になりますので、既にテストを書いたことがある方はコチラから読んでも良いかもしれませんね！

How to test with snapshots　の章では、 renderer メソッドを使用しています。 こちらは　yarn add --dev react-test-renderer² でパッケージを落としてくることで使用することができます。

また、型のチェック部分で使用されている　.toBeString() メソッドは jest のテストメソッドを拡張する jest-extended³ を導入することで使用できます。 他にもテストメソッドに関して API Reference⁴ に多く用意されていますので、迷ったら見にいくのが良いかと思います。

スナップショットテストとは、簡単にユーザインターフェースが変更されていないかをチェックするためにあります。実際にテストとは、ファイルの拡張子より 仕様書 を意味する .spec ファイルになっています。 そう考えてみますと、このテストは「何のために、どのように」行ったのかを第三者に伝える意味も込めて書いて見ると色々と腑に落ちる部分があるかと思います(自分はありました。

参考