必要十分なテストコードについて

こんばんは、素敵な夜ですね。
必要十分なテストコードについて考えた事をまとめる。

プロダクト開発においてテストコードはなくてはならない

その内容について

プログラムの状態は当然無限にある。
どんなに適切に責務を分けても状態は当然無限になる。
なので、全部をテストする事はできない。
ファジーな言い方になるが、どこかで自信と責任を持ってリリースすることしかできない。
それを前提に、下記の考え方ができると思われる。

コードカバレッジ

カバー率の算出方法には複数方式が存在し、それぞれの次元で考える事ができる。

組合せ爆発

一つの機能単位（関数など）に責務をもたせすぎると、当然テストデータ等は爆発的に増加していく。
責務を切り分け、それぞれの機能単位の責任を遂行させる。

テストピラミッド

もちろん、責務を切り分けようが、プログラム全体の状態の総量は変わらない。
とはいえ、それぞれの責任を適切にテストすれば、プログラム全体はある程度動くはず。
そして、総合的な動作を見る自動テストも書くが、それほど量が多くなくて済むようにする。
これは、コストが小さいテストほど増やし、コストが大きいテストほど減らすテストピラミッドの考え方となるのではないか。

プログラムに必要とされる信頼性を考える。

テストの基準は宇宙開発ロケットや医療プログラムと、個人開発のプロトタイプでは全く違う。

アップデートの動作検証

上記の議論とは無関係に、アップデートするときは少なくともステートメントカバレッジ100％がほしい。
動作が壊れていない事を知りたい。
もちろん、ブランチカバレッジも多ければよい。
コンディションカバレッジも多ければよいが、あまりプロダクトの信頼性に関係ない場面も多いと思われる。

結論

一旦暫定的に言葉で言ってしまえば、ステートメントカバレッジ100％を意識しながら、どこまでブランチカバレッジを追いかけるかという話になると考えている。
もっとも、それも全ては状況次第となる。
ご指摘等ありましたら頂けますと幸いです。