メモ
まえがき
単体テストに関する本や記事を読んでも、なんで単体テストが推奨されているのか分からないことが多くてモヤモヤするので、モヤモヤを記事にすることで気を紛らわそうと思う。
ついでに、自分の中で単体テストはこういう感じでやっていこうと思う内容をメモしておく。
前提
この記事では単体テストというのはテストコードを書いてそれを動かすテストのことを指すことにする。
Webアプリの単体テストであることが前提。
単体テストに関する疑問
・単体テストの殆どが実は無意味なのでは？とこっそり思ってる人は多いのでは。
・なんでも単体テストするのは微妙だけど、これだけは単体テストしておくと良いよっていうノウハウが欲しい。
・単体テストコードを見ても何を網羅してるかサッパリ分からないんだけど、何かいい方法はないのだろうか。
・なぜ単体テストを推奨する記事が多いのか？単体テストを疑問視する人が多いけど、記事を書くのが単体テストを効果的に行うコツを知っている技術力の高い人ばかりだから？それとも、自分が知らないだけで単体テストってのはみんな効果を感じながら当たり前のように書いてるのだろうか。
・よく、リファクタリングしたときに単体テスト書いてると嬉しいって書いてあるの見るけど、リファクタリングしたらテストコードあったとしても怖いから結局、結合以降のテストもやるから意味は薄いような気がするし、そもそもリファクタリング殆どしないんだけど。
・効果低い（バグが見つからないのにコスト高い）単体テストよりも結合テストの自動化を頑張った方がいいんじゃないだろうか。
単体テストはこういう感じでやっていこうと思う（暫定）
バリデーションと境界値と計算のテストと実際にDBアクセスするテストは単体テストして、その他は効果ないような気がするので基本的には単体テストしない。
テストコード見ても何を網羅してるのか分からん問題はチームの方針でこれを単体テストするって決めてレビューでそれを網羅できてるか確認すればいいのかも。単体テストのレビューとかしたこともされたこともないけど。。
調査
単体テストのレビューに関して
Javaであれば、JavaDocを見やすくすればある程度はレビューできそう。
レビューというか、自分でテストしてて、境界値テストをどこまで網羅してるのか分からなくなるのを防ぎたい。
フロントエンドのテストに関する記事
複雑なロジックや重要な機能のテストを優先的に書くのはなるほどと思った。