回答:
図から判断すると、Productはテストする機能を持たない愚かなデータクラスです。そこで、最初にLine、次にOrderのテスト（および実装、TDDスタイル）を作成して、依存関係のラダーを作成します。通常、上位レベルのクラス（下位レベルに依存するクラス）で作業を開始する前に、下位レベルのクラスをテストするのが賢明です。これにより、バグをより効率的にキャッチできます。
モックオブジェクトを使用する必要があるかどうかは、テスト対象のクラスの実際の依存関係によって異なります。これらが、テストに必要な任意のデータ/状態を簡単にインスタンス化しセットアップできる単純なクラスである場合、モックは必要ありません。（これは、ここでのサンプルデザインの場合のようです。）ただし、依存関係のいずれかを初期化するのが困難である/広範な依存関係自体がある/望ましくない副作用がある/ DBなどの外部リソースに依存する場合、それは理にかなっています代わりにモックオブジェクトを使用します。
ここでは、モックオブジェクトの必要性はあまりありません。他の人が指摘したように、依存関係を設定するのが難しい場合はほとんど必要になります。
たとえば、コントローラーをテストし、別のコントローラーを呼び出してその情報の一部をCookieに保存する必要があるユーザーログインが必要なときに、Ruby on Railsプロジェクトでそれらを使用しました。この場合、特定のアクセス権限について尋ねられたときにtrueを返すログインユーザーをモックすると便利です。
「TDDは主に、ソースコードが徹底的にユニットテストされることを保証するという副作用を伴う設計手法です」-Scott W. Ambler
アイデアは、単体テストを作成して設計を見つけることです。あなたの場合、すでにデザインが整っているようで、TDDの目的をやや損ねています（デザインが最終的なものであると仮定します）。
ock笑について。モックを作成する場合は、Lineのテストを作成するときにProductをモックし、OrderをテストするときにLineをモックすることをお勧めします。しかし、ここではやり過ぎかもしれません。私は個人的に可能な限りモックを制限し、それを使用して外部クラス（データベースインスタンスなど）への依存関係を分離します。
