テスト駆動の開発(TDD)が優れたデザインを促進するという主張が成された。TDDがアーキテクチャとデザインに悪影響を及ぼすという主張も成された。 抽象性を論じるよりもそれは少し具体性を加えるので私達はプライベートメソッドと優れたデザインとテスト容易性とその関係性に重点を置くことにした。明らかな矛盾の一例である。
Szczepan Faber氏はプライベートメソッドが非パターンである(source)とブログに書いた。
プライベートメソッドの匂いはTDDの誕生と共に発火するように見えました。テスト病にかかった人々は彼らのプライベートメソッドをどのようにテストしたら良いか知りたがったのです。やれやれ・・・それはそんなに簡単な事ではなくその疑問は”どのように”から”なぜ”に発展しました。プライベートメソッドをテストする目的は何でしょうか？ほとんどのテストドリブンデベロッパたちは即座に答えるでしょう。やめておきなさい。(source)それでもまたTDDは私達がソ フトウェアを作る方法を変え、またプライベートメソッドを再評価したのです。：）
Jay Fields氏はRubyにおいてプライベートメソッドをテストする一般的な方法(source)をブログに記載した。
・・・私はプライベートメソッドをめったにテストしません。パブリックAPIを通してテストするのを好みます。しかしながらプライベートメソッド用にテストをいくつか書くのであればもっと生活が楽になる場合があるのです。
Michael Feathers氏はThe Deep Synersy Between Testability and Good Design(source)においてTDDが優れたデザインを促進し、また反対にテスト不可能なコードには再考の余地があることを提示した。
テストを書くとき、またプライベートメソッドをテストする衝動を感じた時、私はそれをヒントと受け取ります。そのヒントは私のクラスが非常にカプセル化されているのでそ、のパブリックインターフェースによって”理解不能”になるように終わっている事を教えてくれます。私はそのヒントに耳を傾けデザインを異なったやり方でファクターするのです。通常私はプライベートメソッドが非プライベートになることが可能で、テストにアクセス可能な新たなクラスにそれ（と可能性 としてその周りのメソッド）を動かすことに終わります。
上記の概念は全てプライベートメソッドを阻止する傾向にあり、またテスト容易性に重点を置いている。しかしながらその課題における言葉はそれだけではなかった。実際のところオブジェクト指向のデザインについて書かれたもののほとんどが最大限のカプセル化とより少数のクラスを後押しするものであった。パブリックAPI内で絶対最小値を表示することのみによって結合が最小限化されるのである。Ojject Thinking(サイト・英語)のDavid West氏はオブジェクト指向のソフトウェア測定基準(source)におけるLorenz氏とKidd氏の文章を引用している。
- アプリケーションは40の階、100以内のクラスで構成されるべきである
- アプリケーションの全体的なビジネスドメインは1000以上のクラスを要するべきではない
- コードの25-30%は反復ごとに捨てられるべきである
- クラスごとの責任：平均7
- クラスごとのメソッド：平均12
- メソッドごとのコードライン：15
- コメントを要するコードラインの%：60
- ケースステートメントの数：平均 0
もしプライベートメソッドがそれらのクラスに引き出される必要があるのなら、私達はテストを簡単にするためだけにアプリケーション内のクラスの数を増やすのではないだろうか？そうすることによってすばやく非常に大数のクラスがもたらされるのである。
プライベートメソッドはどうだろうか？それをテストするのは厄介なのである。プライベートメソッドを変更してテスト用にそれを表示するだろう？プライベートメソッドをテストするのをやめ、デザインをテスト容易性から独立させた状態を保つだろうか？それともプライベートメソッドがあやしいのだろうか－クラスのインディケーションはやりすぎなのだろうか？
原文はこちらです：http://www.infoq.com/news/2008/01/private-methods-tdd-design