プライベートメソッドをユニットテストするかどうかという話題があります。賛否両論ですが、プライベートメソッドはユニットテストしない派の方が主流な印象でしょうか。ただ、個人的にはテストした方がいいと思ってます。その理由は、テストの粒度が下がることによってテスト失敗したときにその原因の追究が容易になることに尽きます。パブリックメソッド経由でテストして、カバレッジ100%なら問題ないという意見は、極論すればテストケースが詳細ならシステムテストだけで十分でユニットテストは不要と言っているのに等しいようにも思えます。それではバグは発見できても、それを修正するのは大変ですよねぇ。
主な主張は以上ですが、以下各論について簡単に述べます。
パブリックメソッド経由でテストすればいい
先ほども述べました通り、それではテストの粒度が大きくなりすぎるように思います。テストの粒度が大きくなるのはクラス設計が大きすぎるので適切にクラスを分割するべきだというのは、それも正論ではありますが。
ユニットテストはクラスの設計書とも言います。パブリックメソッドしかテストしないのは外部設計のみを記述するということと等しいかと思います。一方、プライベートメソッドもテストをするというのは内部設計書も書くということに相当するでしょうか。設計書というと面倒なドキュメント作成を連想していやになりますが、ユニットテストは開発に使うツールですから、詳細な方が開発者自身が助かることになります。リファクタリングして内部実装が変わるのであれば、そのときはユニットテストも書き直せばいいのではないでしょうかね。
プライベートメソッドは詳細な実装なのでユニットテストでは気にするべきではない
ユニットテストを外部設計書だとするならばその意見は正しいですが、内部設計書であるとするなら正しくないことになりますね。
開発時は全てパブリックにしてリリース後にプライベートにすればよい
リリース後に一切コードに手を入れないならそれでもいいですが、コードに手を入れるなら毎回パブリック/プライベートを書き換えるのは論外でしょう。
リフレクションを使う
プライベートメソッドをテストするとして実際にどう実現するかという話になると、まあリフレクションが現実的な方法ということになりますかねぇ。
テストメソッドをクラスに内包する
テストメソッドがクラス内にあれば、プライベートメソッドも呼び放題ですよね。むかーしはこういう書き方もあったように思うのですが、現代では絶滅しているように思います。自分でその書き方をしても構いませんが、テストフレームワークが対応してないので困ったことになるでしょう。