私はTDD環境で働いていますが、基本的にTDD環境で非常に重要だと思うジレンマに直面しています。プログラマーは、メソッドをできるだけ読みやすくしたいと考えています。これを達成するために、メソッドを複数のプライベート メソッドに分割する傾向もあります。そうしている間、プライベート関数に移動されたすべてのコードは、そのテスト能力を失います。
Rhino テスト クラスはこれらすべてのプライベート メソッドを表示できないため、これらのメソッドに対してもテストを実行できる必要があります。それらを公開しておくのは意味がないので、公開したくありません。
何か案は？
あなたの質問の一部を引用すると：
[...] メソッドを複数のプライベート メソッドに分割する傾向があります [...]
これは間違っています。単一責任の原則と優れた OOP 設計に従うと、メソッドはより独立し、よりシンプルになります。公開メソッドを短く見せるためにさらに別のプライベートメソッドを抽出したい場合は、まずそれを検討してください。たぶん、別のクラスでリファクタリングできますか？
実装の詳細ではなくパブリックコントラクトをテストするため、プライベートメソッドはテストしません。プライベートメソッドのテストに非常に似たものが必要な場合は、それらをinternalにして属性を設定します。InternalsVisibleTo
もう 1 つの方法 (R. Harvey が指摘) は、プライベートメソッドをパブリックメソッドにラップするラッパー クラスを作成することです。このアプローチには、プライベートメソッドをinternalにする必要がないという利点があります。欠点は、すべてのプライベートメソッドに対して、ラッパーのパブリックメソッドが存在することです。したがって、メソッドの量は 2 倍になる可能性があります。
他の人が示唆しているように、非パブリック メソッドをテストする 1 つの方法は、それらを内部にしてInternalsVisibleTo属性を使用することです。しかし、私はそれに対して強く提案します。
プライベート メソッドは、それらを使用するパブリック メソッドをテストすることにより、単体テストでカバーする必要があります。もちろん、時間が経過し、テスト対象のクラスに機能を追加するにつれて、テストのセットアップはますます複雑になります。これは、クラスの責任が大きすぎるため、複数の小さなクラスに分割する必要があることを示す良い指標です。次に、これらの小さなクラスを元のクラスの依存関係にして、テストでそれらをモックできます。これにより、テストが再び簡素化されます。
その際、プライベート メソッドを完全に放棄する必要はありません。コメントを使用せずにコードを読みやすくするためにプライベート メソッドを使用することをお勧めします。