[解決済み] ユニットテストはどれだけ深いか？

質問

TDDについてわかったことは、テストをセットアップするのに時間がかかるということと、生まれつきの怠け者なので、できるだけ少ないコードを書きたいということです。私が最初にすることは、コンストラクタがすべてのプロパティを設定したことをテストすることですが、これはやりすぎでしょうか？

私の質問は、どの程度の粒度でユニットテストを書いているかということです。

...そして、テストが多すぎるということはないのでしょうか？

どのように解決するのですか？

私はテストではなく、動作するコードに対して報酬を得ているので、私の哲学は、与えられた信頼性のレベル (この信頼性のレベルは業界の標準と比較して高いと思われますが、それは単なる思い上がりかもしれません) に達するために、できる限り少ないテストをすることです。もし私が一般的にある種のミス（コンストラクタに間違った変数を設定するような）をしないのであれば、私はそのためのテストを行いません。テストエラーに意味を見出す傾向があるので、複雑な条件分岐を含むロジックの場合は特に注意しています。チームでコーディングするときは、私たち全員が間違えやすいコードを注意深くテストするように戦略を変更します。

人によって、この哲学に基づいたテスト戦略は異なるでしょうが、テストがコーディングのインナーループにどのように最適にフィットするかについての理解が未熟であることを考えると、私にはそれが合理的であるように思われます。10 年後、20 年後には、どのテストを書くべきか、どのテストを書かないべきか、そしてどのようにその違いを見分けるかについて、より普遍的な理論が確立されていることでしょう。それまでは、実験が必要なようです。