はーあずにゃん
@charsiuCat I/Fの公開度とか副作用の有無みたいな外形的な基準でテスト対象かどうかを判断すると訳分からなくなりがちなので、なぜテストを書くのかの原点に戻って、とにかく壊れたらヤバいロジックをカバーすることを第一目標にする(重要度が低いとこは最悪諦める)のが結局一番良いという気持ちになっています
仕様書がない、というか一般に関数やモジュールのinvariantを定義してないならテスト不可です
privateなメソッドにテストを書くなというやつ不勉強ながら原典を知らないんだけど、おそらく元々は「書くな」とは言ってなくて、privateメソッドをテストしただけで公開I/Fがテストされたと思うなよ?の意味なんじゃないかと思っています
プログラムの壊れ方をいろいろ見たことがないと何をテストすればいいのか分からないというのはありそう
個人的にはだいたい「対象になる関数やロジックのinvariantを一息で説明できなければテストを書いた方がいい」くらいの基準でやっています
invariantというかcontract?プログラミング文脈での使い分けがよく分かっていない
Genericsの話題で出てくるinvariant/covariant/contravariantって元々どの分野の言葉なんだろう