フロントエンドのテスト戦略の記事を読んだ

読んだ。

テストについては初心者といっても差し支えないレベルなので、こういう記事はあればあるほどありがたい。

テストを書くのは、やはり

手動でのテストではなく、自動テストを書くことで、ある一つの変更によって不具合を混在させていないことを事前に検知でき、変更のコストが下がることで、結果として品質の高いコードをリリースできるようになります。

これが大きいなあ。

テストを書くコスト、テストのメンテナンスコストもあるが、テストを書かないことで生じるリスクのほうが大きい場合がほとんどというイメージがある。スピード重視とかクオリティ重視とかの話も、結果としてクオリティに振ったほうがスピードも早くなる、みたいな。

正しい箇所に正しくテストを書かないと、テスト自体もソフトウェアであるので、負債を生むことになり、そうした点もテストを書くにあたって考慮しなくてはいけません。

これが難しい。テストがバグっていたら余計なコストになるし、テストを正しく書く技術が必要。

フロントエンドでは4種類あるが、Linter/Formatterなどを使ったものを静的テストというらしい。これもテストなのかという学び。

あとは単体(ユニット)、結合(インテグレーション)、UI(E2E)という感じ。ここらへんは最近学んできたので、種類や分別はつくようになった。

先程も書いたとおり、テストはコストがかかるが、書かないとリスクがある。

どこまでコストを払ってどこまでのリスクを許容するかという話で、静的テストや単体テストはコストは低いが担保できる部分が小さく、結合テストやE2Eテストはコストが高いがアプリケーションの大きな部分の動作保証ができる。

それぞれのテストには上記に挙げた観点でメリット・デメリットが存在するので、それぞれを比較・検討した上で、どのテストを、どこの機能に、どの粒度でテストを書くか、テスト戦略を立てる必要があります。

これをプロダクトやチームごとに見定めて、どういったところまでテストを書いていくのかを決めるのがよさそう。

この記事で個人的にとても参考になるのが、このテスト戦略の部分かなと思う。

上記のテストの種類の中でも結合テストがコスパが良く、ここを厚めに書くのがいいとのこと。

結合テストにも色々な切り口があり、この記事ではContainer/Presentetionalで分けているコンポーネントのContainerの部分を厚めに書くことで、外部APIとの連携のhooksやビジネスロジックを担保するようにしているらしい。

たしかに、一箇所(言い方が難しい)のテストで担保できる部分が大きく、簡単な単体テストをいくつも書くよりここを厚めに書いたほうがよさそうな感じがある。

E2Eテストに関しても、特に重要な部分を書くとある。バグが発生するとインパクトが大きい部分であるタイムラインや課金導線を優先すべきなのはとても納得できる。

また、単体テストも簡単なところを厚く書くより複雑な部分を書くほうが得られるものが多そう。

静的テストに関しても納得で、最初に入れるほうが明らかにコストがかからない。静的テストに関しては普段から「もし新しくプロジェクトを作るとしたらこれ」というのをしっかり定めておきたい。

総じて納得感が高く、学びも多い記事でとてもありがたかった。