釣りキチプログラマー翔平の備忘録 
はじめに
この記事では、
僕の10年間現場でテストコードを書いて失敗してきた経験、
書籍・勉強会などを通じて学習した内容、
などを言語化して、
もし新人プログラマー時代の自分にテストコードについて伝えるとしたら？？
というテーマでまとめてみました。
自分の後輩含め若手プログラマーの方々の参考になればと思います。
テストコードはなぜ必要なのか？？
まずはテストコードがなぜ必要なのか？？
どういった箇所にどんなテストコードが必要で、
逆にどういう箇所にはテストコードが不要なのか？？
について理解するところから始めましょう。
他の人が書いているからとか、
現場の開発ルールがとか、
ただそれだけの理由で無駄にテストコードを増やして
保守コストを上げてしまっていませんでしょうか？？
質の良いテストコードとは何で、
どこに注意してテストコードを書けば良いのでしょうか？？
このあたりを記事や動画にまとめたのでご覧ください。
テストコードが必要な理由とテストコードの間違った考え方
テストコードを書くときに大切な考え方
ここからは、
自分が現場で失敗してきた体験や
書籍や勉強会を通じて学んできたことをベースに
現場でテストコードを書く際に、
自分が大切にしている考え方や気をつけていることなどを紹介していきます。
質の高いテストコードを書くにはバランスを意識する
質の高いテストコードには以下4つの特徴を備えさせる必要があります。
- リファクタリングへの耐性
- 迅速なフィードバック
- 退行に対する保護
- 保守のしやすさ
1つのテストケースにこれら全て完璧に備えさせるのは不可能な一方で、
どれか1つでもゼロになってしまうと、
そのテストケースの価値もゼロになります。
その中で、どのようにバランスを取るのが良いか？？
について記事や動画にまとめたのでご覧ください。
テストコードに備えさせる4つの特徴とバランス〜テストコードのきほん〜
テスト対象を4つに分類して考える
テストコードを書くべきか？？
書かないべきか？？
テスト対象のリファクタリングからするか？？
テストコードを書く前には、
テスト対象を分類してそれぞれに適切な対応をしていく必要があります。
例えばテスト対象の設計が悪いせいで、
テストが書きずらいのに、
テストコードを複雑にしてテストコードだけでなんとかしようとしてはダメです。
この辺りについて記事や動画にまとめたのでご覧ください。
テスト対象を分析して4つに分ける〜テストコードのきほん〜
テストコードで検証すべき箇所とすべきでない箇所
質の高いテストコードが備えるべき特徴の1つに
リファクタリングへの耐性があります。
テストコードを書く際、
退行(リグレッション)に対する保護のみを気にして、
リファクタリングへの耐性が疎かになり、
保守開発のフェーズで、
プロダクションコードをリファクタリングするとテストコードが
嘘の警告(テスト結果がOKになるべきなのにNGになる)をするようになる。
というケースを現場でよく見かけます。
嘘の警告を減らして、
リファクタリングへの耐性をテストコードに備えさせるには？？
について記事にまとめたのでご覧ください。
検証する箇所としない箇所〜テストコードのきほん〜
テストコードでモックやスタブを利用する時の注意点
複雑な依存関係のあるテスト対象をテストする際、
モックやスタブを利用します。
しかしこれらを過剰に利用すると、
テストコードが実装の詳細と結びつき
リファクタリングへの耐性を失います。
また、モックやスタブを検討する中で、
テスト対象の設計の歪さの検知につながることもあります。
このあたりについて記事や動画にまとめたのでご覧ください。
モックとスタブの注意点とポイント〜テストコードのきほん〜
統合・E2Eテストコードを書く際の注意点
ここからは自分が現場で統合テストやE2Eテストを書く際、
大事にしている考え方や注意している点について紹介していきます。
データベースに対するテスト
統合テストなどではデータベースと繋いだテストコードを書くケースも多いと思います。
データベースに対するテストは注意点が多く、
不用意に何も考えずにテストコードを書くと、
リファクタリングに弱く、保守コストばかりが無駄に高くなってしまいます。
実際にそのような現場を僕も見てきて、
今後テストケースを書く際にはこれだけは注意した方が良い。
という部分を厳選してまとめたのでご覧ください。
データベースに対するテスト〜テストコードのきほん〜
今後現場での経験や学習を通じて得た知識は随時追加していきます！！！
