純粋な答えは、プライベート メソッドがそのように呼び出されるのには理由があるということです。;-)
質問をひっくり返します。(一般にアクセス可能な) インターフェイスの仕様だけが与えられた場合、コードを記述する前にテスト計画をどのようにレイアウトしますか? そのインターフェイスは、それを実装するオブジェクトの予想される動作を記述します。そのレベルでテストできない場合は、設計に問題があります。
たとえば、運送会社の場合、次の (疑似コード化された) インターフェースを使用できます。
CapitalAsset {
Money getPurchaseCost();
Money getCurrentValue();
Date whenPurchased();
...
}
PeopleMover {
Weight getVehicleWeight();
int getPersonCapacitly();
int getMilesOnFullTank();
Money getCostPerPersonMileFullyLoaded(Money fuelPerGallon);
...
}
これらを含むクラスを持つ場合があります。
Bus implements CapitalAsset, PeopleMover {
Account getCurrentAdvertiser() {...}
boolean getArticulated() {...}
...
}
Computer implements CapitalAsset {
boolean isRacked() {...}
...
}
Van implements CapitalAsset, PeopleMover {
boolean getWheelchairEnabled() {...}
...
}
コンセプトとインターフェイスを設計するとき、のインスタンスがどのCapitalAsset
ように動作するかについて、財務担当者と合意する必要がありました。その合意のみに依存するテストを作成します。どの具象クラスが関与しているかに依存することなく、 、、および同様にこれらのテストを実行できるはずです。についても同様です。CapitalAsset
CapitalAsset
Bus
Computer
Van
PeopleMover
Bus
の一般的な契約から独立しているCapitalAsset
aについて何かをテストする必要がある場合は、PeopleMover
別のバス テストが必要です。
特定の具象クラスに含まれる public メソッドが非常に複雑で、TDD や BDD が期待される動作をきれいに表現できない場合、これもまた、何かが間違っているという手がかりになります。具象クラスにプライベートな「ヘルパー」メソッドがある場合、それらは特定の理由でそこにある必要があります。「このヘルパーに欠陥があった場合、どのような公共の行動が (そしてどのように) 影響を受けるでしょうか?」という質問をすることができるはずです。
正当な固有の複雑さ (つまり、問題のドメインに由来する複雑さ) については、クラスが特定の概念を担当するヘルパークラスのプライベート インスタンスを持つことが適切な場合があります。その場合、ヘルパー クラスは単独でテストできる必要があります。
良い経験則は次のとおりです。
複雑すぎてテストできない場合は、複雑すぎます。