POODRなどの本から TDD に関して私が見た一般的なアドバイスは、プライベート メソッドをテストしないことです。プライベート メソッドを呼び出すパブリック メソッドがテストされ、プライベート メソッドを検証するのに十分なはずであるという考えです。
これは理にかなっていますが、プライベート メソッドが複数の「層」の深さである場合はどうでしょうか。これが私が言いたいことの不自然な例です：
public
# test this method
def foo
private1
end
private
def private1
private2
end
def private2
private3
end
def private3
# does stuff
end
共有する実際の例はありませんが、このような場合、 public メソッドをテストするだけで十分fooですか? それとも、このように構成されたコードは、おそらくより深い問題を示しているのでしょうか?
この背後にある考え方は、クラスの内部はそのクラスの実装の詳細であるということです。
あなたの不自然な例は、 foo からの出力のみをユーザーに公開します。したがって、テストが変更されないようにする必要があるのはそれだけです。
クラス全体を foo のような 10 個のメソッドで DRY アップして、内部で 1 つのメソッドのみを使用する場合、private に変更したためにテストが中断することは望ましくありません。パブリック インターフェイスがまだ機能している限り、内部をテストする必要はありません。
この背後にある原則はカプセル化です。あなたのクラスがカバーの下で何をしているのかは気にしません - 出力が正しい限り、量子コンピュータ上で実行し、そのデータストリームを月にいる人に送信して計算を行うことができます.正しく期待される結果が表示されます。
プライベートをテストしようとしても、これらのメソッドを変更するとテストが中断するだけです。多くの場合はこれで問題ありませんが、過剰なテストを行うと、生産性よりも壊れたテストの修正に多くの時間を費やすことになります。
もちろん、このアドバイスは常に状況によって異なります。この 1 つの方法が機能することが重要であると感じる場合は、そのためのテストを作成することをお勧めします。しかし、これらのテストは、いずれにせよ、パブリック メソッド用に既に用意されているテストのほとんどが複製されています。
他のオブジェクトが依存する唯一のメソッドであるため、#foo のみをテストします。foo が想定どおりの動作をすることをテストが「証明」する場合、これを達成するために呼び出されるプライベート メソッドの数は問題ではありません。
テスト手法をさらに詳しく説明している Sandy Metz による次の講演をお勧めします: http://www.youtube.com/watch?v=URSWYvyc42M
しかし、私はあなたの懸念を理解しています。プライベート メソッドの 1 つに自信が持てない場合は、メソッドに自信を持つためにいくつかのテストを作成してもかまいませんが、これらのテストを維持するために多くの時間を無駄にしないでください。
いくつかの実装の詳細を変更し、#private2 のテストが失敗したとしますが、#foo のテストはまだグリーンです。#private2 の修正にあまり時間をかけません。(つまり、#private2 のテストを削除します)
他のプライベート関数をテストするには、関数 foo をテストするだけで十分だと思います。深いレベルの関数呼び出しに問題はありません。ユニットとしての Foo 関数は、すべてのアサーションで機能するはずです。
テストを変更せずに実装を変更するための適度な柔軟性を維持しながら、コードとの外部対話が安全で期待どおりに機能することを確認したいので、パブリック インターフェイスをテストすることは理にかなっています。
プライベート メソッドに含まれる概念が複雑で興味深いと思われる場合は、それを別のクラスに変換し、新しいパブリック インターフェイスを作成して、それらのテストを作成することをお勧めします。SOLID原則などのクラスをいつクリーンアップするかを決定するのに役立つアドバイスがたくさんあります
維持するつもりのないテストやコードを書くことについて考えないでください。