EasyMock 3.0 のドキュメント (http://www.easymock.org/EasyMock3_0_Documentation.html) では、そうであると主張されていますが、その理由は説明されていません (強調は私のものです)。
クラスの一部のメソッドのみをモックし、他のメソッドの通常の動作を維持する必要がある場合があります。これは通常 、同じクラス内の他のメソッドを呼び出すメソッドをテストする場合に発生します。したがって、テストされたメソッドの通常の動作を維持し、他のメソッドをモックする必要があります。
この場合、最初に行うべきことは、リファクタリングを検討することです。これは、 ほとんどの場合、この問題は不適切な設計によって引き起こされるためです。
それで、これは正しいですか？なぜ？
問題は独自のメソッドを呼び出すことではなく、それらの呼び出しをモックする必要があるということは、別の問題を示しています。それ以外の場合は、パブリック メソッドをテストして、その動作を確認するだけです。他のメソッドが呼び出すものを気にする必要はありませんが、観察可能な動作だけを気にする必要があります。
いつものように、それは依存します。
メソッドは常に他のメソッドを呼び出します。これは、(IMO の適切な) リファクタリングの自然な結果であり、他のメソッドをサイズに合わせてスライスします。私にとっての問題は、これらの小さな適切なメソッドをモックする必要があり、そうしないとテストできないという点にあります。
小さなメソッドがたくさんある場合は、何らかのコラボレーター クラスに適切にラップされている可能性があります。その時点で、内部メソッドの代わりにコラボレーターをモックします。
また、これらの小さな内部メソッドはプライベート メソッドである可能性があり、そのテストは議論の対象となります。