いつモックオブジェクトを使うべきですか？
私はTDDについて多くのことを読みましたが、まだ疑問があります。たとえば、次のクラス図があります。
これは、TDDとモックオブジェクトについて学ぶための単純な例です。
最初にどのテストを書くべきですか？ Product、次にLineそして最後に、Order？その場合、LineとProductを使用してOrderをテストする必要がありますか、それともモックオブジェクトを使用する必要がありますか？いつモックオブジェクトを使用すればよいですか？ XPおよびTDDでUMLを使用する必要がありますか？
私はまだこれらのものを手に入れていません。
図から判断すると、Productはダムデータクラスであり、テストする機能はありません。したがって、最初にLineのテスト（およびTDDスタイルの実装）を作成し、次にOrderを作成して、依存関係ラダーを作成します。通常、より高いレベルのクラス（つまり、より低いレベルに依存するクラス）で作業を開始する前に、より低いレベルのクラスをテストするのが賢明です。これにより、バグの検出がより効率的になります。
モックオブジェクトを使用する必要があるかどうかは、テストしたクラスの実際の依存関係によって異なります。これらが単純なクラスであり、簡単にインスタンス化して、テストに必要な任意のデータ/状態を設定できる場合は、モックは必要ありません。 （これは、ここでのサンプルデザインの場合に当てはまるようです。）ただし、依存関係のいずれかが初期化するのが難しい場合/依存関係自体が広範囲に及ぶ場合/望ましくない副作用がある場合/ DBなどの外部リソースに依存する場合、それは理にかなっています代わりにモックオブジェクトを使用します。
ここではモックオブジェクトの必要性はあまりありません。他の人が指摘したように、依存関係の設定が難しい場合は、ほとんどが必要です。
たとえば、コントローラをテストしたときにRuby on Railsプロジェクト）でそれらを使用し、別のコントローラへの呼び出しと、この場合、特定のアクセス権限について尋ねられたときに、trueを返すログインユーザーを模擬すると役立ちます。
「TDDは主に、ソースコードが完全にユニットテストされることを保証するという副作用のある設計手法です。」-Scott W. Ambler
アイデアは、ユニットテストを書くことによってデザインを見つけることです。あなたのケースでは、すでに設計が整っているようですが、これはTDDの目的に少し反しています（設計が最終的なものであると仮定した場合）。
あざけることについて。モックしたい場合は、Lineのテストを作成するときにProductをモックし、OrderをテストするときにLineをモックすることをお勧めします。しかし、ここではやり過ぎかもしれません。私は個人的にモッキングを可能な限り制限し、それを使用して外部クラス（データベースインスタンスなど）への依存関係を分離します。
通常、テストでは、テスト対象のシステム/オブジェクトを分離したいので、それ以外のすべてのものを模擬します。したがって、クラス図を使用して、注文オブジェクトをテストするときは、ラインオブジェクトにモックを使用します。 Lineをテストするときは、注文と製品のモックを使用します。製品をテストするときは、ラインにモックを使用します。