メモ
まえがき
単体テストに関する本や記事を読んでも、なんで単体テストが推奨されているのか分からないことが多くてモヤモヤするので、モヤモヤを記事にすることで気を紛らわそうと思う。
ついでに、自分の中で単体テストはこういう感じでやっていこうと思う内容をメモしておく。
前提
この記事では単体テストというのはテストコードを書いてそれを動かすテストのことを指すことにする。
Webアプリの単体テストであることが前提。
単体テストに関する疑問
・単体テストの殆どが実は無意味なのでは？とこっそり思ってる人は多いのでは。
・なんでも単体テストするのは微妙だけど、これだけは単体テストしておくと良いよっていうノウハウが欲しい。
・単体テストコードを見ても何を網羅してるかサッパリ分からないんだけど、何かいい方法はないのだろうか。
・なぜ単体テストを推奨する記事が多いのか？単体テストを疑問視する人が多いけど、記事を書くのが単体テストを効果的に行うコツを知っている技術力の高い人ばかりだから？それとも、自分が知らないだけで単体テストってのはみんな効果を感じながら当たり前のように書いてるのだろうか。
・よく、リファクタリングしたときに単体テスト書いてると嬉しいって書いてあるの見るけど、リファクタリングしたらテストコードあったとしても怖いから結局、結合以降のテストもやるから意味は薄いような気がするし、そもそもリファクタリング殆どしないんだけど。
・効果低い（バグが見つからないのにコスト高い）単体テストよりも結合テストの自動化を頑張った方がいいんじゃないだろうか。
単体テストはこういう感じでやっていこうと思う（暫定）
バリデーションと境界値と計算のテストと実際にDBアクセスするテストは単体テストして、その他は効果ないような気がするので基本的には単体テストしない。
テストコード見ても何を網羅してるのか分からん問題はチームの方針でこれを単体テストするって決めてレビューでそれを網羅できてるか確認すればいいのかも。単体テストのレビューとかしたこともされたこともないけど。。
調査
単体テストのレビューに関して
Javaであれば、JavaDocを見やすくすればある程度はレビューできそう。
レビューというか、自分でテストしてて、境界値テストをどこまで網羅してるのか分からなくなるのを防ぎたい。
フロントエンドのテストに関する記事
複雑なロジックや重要な機能のテストを優先的に書くのはなるほどと思った。
テストのメリット（Railsチュートリアルより引用）
・テストが揃っていれば、機能停止に陥るような回帰バグ（Regression Bug: 以前のバグが再発したり機能の追加/変更に副作用が生じたりすること）を防止できる。
・テストが揃っていれば、コードを安全にリファクタリング（機能を変更せずにコードを改善）できる。
・テストコードは、アプリケーションコードから見ればクライアントとして動作するので、アプリケーションの設計やシステムの他の部分とのインターフェイスを決めるときにも役に立つ。
テストを書くタイミング（Railsチュートリアルより引用）
・アプリケーションのコードよりも明らかにテストコードの方が短くシンプルになる（=簡単に書ける）のであれば、「先に」書く
・動作の仕様がまだ固まりきっていない場合、アプリケーションのコードを先に書き、期待する動作を「後で」書く
・セキュリティが重要な課題またはセキュリティ周りのエラーが発生した場合、テストを「先に」書く
・バグを見つけたら、そのバグを再現するテストを「先に」書き、回帰バグを防ぐ体制を整えてから修正に取りかかる
・すぐにまた変更しそうなコード（HTML構造の細部など）に対するテストは「後で」書く
・リファクタリングするときは「先に」テストを書く。特に、エラーを起こしそうなコードや止まってしまいそうなコードを集中的にテストする７
自動テストの対象
・特定のURLにアクセスしたら200が返却されること
・特定のリンクをクリックしたら特定の画面が表示されること
・アプリケーションのHTML構造を調べて、レイアウトの各リンクが正しく動くかどうかチェック
（railsの場合、「rails generate integration_test」）
あとで読みたい