public functionのみtestすべきという主張
black-box testをしろということ
>#WIP
主張の意図
実装の詳細をtestしないとだいたい同じ
private functionをtestのためだけにpublicにするとカプセル化が壊れる
これは機能がしょぼいだけで本来の問題の理由になっていない
違和感がわかってきたかも
実装の詳細をtestしないには同意できるが、
public functionのみtestすべきという主張は同意できない感じがする
public functionのみtestすべきという主張は、主張が具体的すぎるからだ
主張自体に詳細が現れている
moduleの構成方法に依存してしまっている
publicかどうかはmoduleの作り方に大きく依存する
private functionはtestすべきでない、というのならまずmoduleの作り方を厳密に定義すべき
testを書くかどうかの判断基準がpublic/privateなのがおかしい
「リファクタリングする際に壊れるポイント」の判断基準と合致していない説
そのmoduleの公開範囲と、そのmodule内の関数の定義の仕方に密接な関係はない
moduleの公開範囲は、そのmoduleの利用者のInterfaceの良し悪しによって判断される
複雑な箇所は隠蔽し、意図どおりに使える箇所のみを公開する
ロジックの本質となる部分はprivateの中に封印する
そう考えれば、testしたい箇所は2種類ある
そのInterfaceに沿った使用が適切にできるか
これはpublic functionに対するtestを書けば良い
そのロジックが正しく動作しているか
これはprivate functionに対するtestを書くべき
その個々の小さい関数を、それに限定して網羅性をtestしたいことはよくある
Interfaceを制限しているおかげで、適切に、少ないパターンでtestを書ける
この性質と、この関数が公開されているかどうかは関係が無いと思う
リファクタリングで問題になるにしても、その関数が最もatomicな単位である場合、リファクタリングの妨げにもならないだろうと思う
基本的にはtestしない
private methodは実装詳細なので
外部から見た振る舞いをtestできれば十分
するなら、
パブリックメソッド経由でテストする
別クラスのパブリックメソッドとする
テスト対象の可視性を（やや）上げる
プライベートのまま、リフレクションでアクセスしてテストを書く
「実装の詳細をtestしない」ことが全ての前提に存在する
>プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを示唆している場合があります。
その前提を取っ払えば、この辺の主張はだいぶ違和感がある
「公開の函数のみをテストすべし」は本当か？という主張
>この場合，内部実装が適切に網羅的にチェックされているかをテストが概念上感知しないという点に問題が生じる．技術的には勿論カバレッジを取るなどして網羅性を定量的に推測することが可能だが，もしカバレッジの不足に応じてテストを追加するというリアクションをとるのであれば，それは結局どんなテストを用意すべきかが内部実装に依存しているということであり，幾分か自家撞着的だ．
public testだけだと、testの網羅性を感知しないことを意味する
ただし、test coverageを見て、テストを追加することはできる
しかし、それだと内部を見てテストをしているのと同じ
内部実装が変わればtest coverageも変わるので、testを追加することになる