そもそもカバレッジの見方がよくわからんが、カバレッジを見ると何がいいのか? リファクタリングするにあたって表示するようにしてみたけど、テストを書いていったとしてもコードが実行されたかどうかしかみてないからテストをほとんど書いていなくても実行さえしてしまえばカバレッジは上がる。

つまり高いといいってものでもない。

おそらく最終的には、何をテストしたいかになってくるんだと思う。

低いからと言って闇雲にテストを追加してカバレッジをあげたとしてもあんまり意味なさそう。 テストしたいこと、動作がちゃんと動いているかどうかをテストで書く。

フロントエンドだと結合テストやE2Eテストは準備がめんどくさいけどユニットテストだと難しくない。

結局はそう言う抽象的なコンポーネントだと依存が大きくてテストを書くのに時間がかかる。だから小さい単位でテストを書いて、それだとコンポーネント同士の動作がうまく言ってるか分からないから結合テストを書く。

できる限り小さいコンポーネントで済ませつつ大きなコンポーネントでもテストする、その取捨選択をどうするかのトレードオフを考えながらテストを書いていくほうが大事な気する。カバレッジはあくまでそれらにテストが書かれていなくて実行されていない処理があると言うのを表示してくれるだけ。

テストしたいものがどのレイヤーでテストできていればいいか? コストを比較してユニットテストで書くのか結合テストにするのかを判断できるようになりたいな。

要はテストを書いて書きまくって覚えるしかない。

実装の詳細はテストしない

あくまでテストするのは機能としての結果や振る舞いをテストする。特定の実装に依存したテストを書いてしまうとそこが変わると壊れるテストになってしまう。 挙動の結果さえテストできていれば基本的には仕様が変わるとかがなければテストは壊れない状態が望ましいみたい。 こういうテスト書けるようになりたいな。

collectCoverageFrom

jestでカバレッジを見るときにテストされていないファイルをみる方法ないのかなって思って調べてみたけどあるみたい jest.config.jsに追記したらテストが書かれていないファイルも表示してくれるようになる。

collectCoverageFrom: ["src/**/*.{ts,tsx,js,jsx}"];

Atomic Design

コンポーネントを分けるデザインパターンとしてはいいんだろうけど、ルールが明確に決まってるわけではなかったり各々の感覚にブレが合ったりとどれがどのレイヤーになるのかが難しい。明確に分解できないとかの判断基準はあるけどいまいちこれは無理みたいな判断基準ではない気がするのである。

あんまり個人的にはハマってなくて他にいいやり方あったら乗り換えたさはある。

更新日時: