テストちょっと楽しいかも

最初に言っとくとまだ始めたばかりで一つのテストをどう書けばいいのか試行錯誤しながらやっててまだ一つも通るテストはかけてないよ（おい）

ただ、テストをやってみる前は難しいってイメージがずっと付き纏っていたし、複雑なコンポーネントはテストしづらいんでしょって偏見持ってたりしてあまりテストに対してやる気はなかった。

そろそろエンジニアとしてテストの一つや二つかけるよって言いたいので最近は勉強した内容をプロダクトのコードでどうやってテストしていこうかってずっと考えてる。 今やってるのとしては、とりあえず自分が実装したコードでちゃんと意図した結果になってるかどうかだけをテストしている。

プロジェクトのコードはまだテストしている箇所が少なくて、さすがに全てのテストケースを網羅したテストを書くとかは難しい。途中から入ったから正直元の実装がわからないってのもある。

なので、まずは適当でもいいから期待する結果になってるかどうかをテストしてる感じ。自分のテストコードを書いていくスキルをつけるための練習でもあるからとりあえず間違ってても書いていきつつやってる感じかなー。

案外複雑なコンポーネントでも書こうと思えば書いていける

複雑なコンポーネントというか煩雑なコンポーネントであったり多くの依存があったりってのはテストしづらいって思ってたけど、案外なんとかなる？

まだ明確にやりやすいって言語化はできてないけど、体感テストをやるようになってから案外難しくないのではと思い始めてきた。 それが何かはこれから探す。

フロントエンドってユニットテストももちろんあると思うけど、ユーザーが操作した結果ブラウザの要素がどうなってるかみたいなのをテストしたりする時に案外内部の実装までテストしなくてもなんとかなるって感覚がある。

だから、基本どのコンポーネントでやるにしてもテストできる？（準備がめんどくさいだけ）

悩む点

Providerとか初期化したりがめんどくさい、Reduxを初期化していないとuseSelectorを使うところでエラーになったりする。こういうコンポーネント側で初期化されてないと使えないよみたいな依存を初期化したりするのがめんどくさい。

最初今やっているのが結合テストだと思ったので、テストする場所以外のuseSelectorとかそういうもの全てmockにしたらいいのかなと思っていたけど、どうやらそうでもないみたい。むしろmockを使うと実装が壊れていても気づけない可能性があるっていうのを聞いて「じゃあどういった時にmock使うん？」ってなってるところ。

このmockの使い所みたいなのがいまいち読めないんよなー。DBとかAPIをmockするってのはなんとなくわかるし実装していく中で今はまだできてないからmockにするってのもわかるがなんかテスト書くってなると何をmockにしてたらいいのかが分からない。具体的に処理を行う時にその部分の結果を自由に変えてこの機能をテストしたいみたいな時には実装コードだと試せないからmockするとかなのかな？

Reduxの公式もmockを作らずに、Provider作ってラップしてやってって感じで言ってる

https://redux.js.org/usage/writing-tests

Do not try to mock selector functions or the React-Redux hooks! Mocking imports from libraries is fragile, and doesn’t give you confidence that your actual app code is working.

セレクター関数や React-Redux フックをモックしようとしないでください。ライブラリからのインポートのモック化は脆弱であり、実際のアプリ コードが動作しているという確信が持てません。

ただProviderでラップしたら使えるとかならいいけど、色々やることあるとかだったら辛そう。

あと、個人的にめっちゃ悩むのはPropsを渡したりするのがめんどくさい。 プロジェクトにもよるやろうけど、Reduxで取得したAPIの値をそのまま一気にPropsとして渡してるコンポーネントでテストするってなると、そもそもPropsに渡す初期値何がいいんってなる。 仕様を把握していたりするなら別に問題ないかもしれないけど、このプロパティが何に使われているのか、これを表示するにはこのプロパティのこれじゃなきゃダメとかあるとうーんわからん。ってなる。

結局は今、自分がテストしたい状態を表現する最小限のpropsだけ設定してあとは適当に設定している。。 できればユースケースごとに分けたり自動で作ったり初期化関数があったりした方がいいんやろうけど今現状どうすればいいのかもよく分からん。まずはテストしたい条件を発生させるpropsをいっぱい作って愚直にやっていくが今のワイにできる精一杯の努力です。。

testing-library/react

getByRoleとかがようやく何をしたいのかわかってきた。 testing-library/reactがscreenとかrenderあたりのUIコンポーネントをテストしやすくしてくれてる。 ほいでtoHaveTextContentなどのマッチャー系はtesting-library/jest-domで別なのが少しややこしい。

DOMを操作するって部分は共通やからそのDOMの操作ってことでjest-domって形でマッチャーが分かれてるんだろうけど初見じゃ分からん。 さらに、testing-library/reactはtesting-library/domを拡張しているものやからさらに訳わからんティ

screen.getByRoleって何してるのか理解しづらかったけど、htmlのタグを見つけるためのセレクターって感じで思ったらなんとなくわかってきた。

どのDOM要素かを調べて、あとはその値がどうなってるかをtoHaveTextContentとかで検証していくって感じは理解できて腑に落ちてきた。

ただ、同じ要素が多かったり、被ってる要素がいくつかあったりでうまく検索できないのが課題。 コンポーネントにdata-testidをつけても実際DOMとして表示されるタグについてないといけないっぽいのでちょっとだるい。。