私は新しいユニット（A）を実装し、そのユニットのテストを書いてこのユニットに依存性が必要です（B）。それはまだ存在しません。私のテストでは、この依存関係を模擬するのは簡単ですが、私の生産コードでは何をしますか？TDDを実行しているときに、新しいmocked依存関係をいつ実装するのですか？
最初に（B）を実装していますが、（A）に対する私のテストは、まだテストをパスするために実装していないために失敗しました。
または（A）を最初に完了し、（B）のテストを失敗させます。実際にその仕様が指示するように指示するのではなく、単に "空の"オブジェクトを返します。
または（B）のテストでは、（A）を実装している間に「空」のオブジェクトを返すことを一時的にチェックする必要がありますか？
TDDの基本的な戦略は、あなたが今作業しているものを除いて、すべてのテストを合格に保つことです。あなたが心配する前に（A）のテストをパスする（B）。
あなたはクラスのテストやコードを書くと思いれる順番（A）とその複雑な依存関係（B）は
この時点で、（A）または（B）でさらに作業するか、新しいものを開始するかを選択できます。
この戦略では、テストを常に成功させることができますが、アプリケーションがすぐに役立つものであることを保証するものではありません。あなたのアプリケーションが最終的に何か有益であることを確実にする方法は、受け入れテストとユニットテストがすべて合格するまで受け入れテスト（モックなしでアプリケーション全体に対して実行される）とTDDを書くことから始まります。
アクセプタンステスト（または他の統合テスト）では、モックされたクラスのテストとコーディングされたクラスのコードで、モックを正しく複製することも保証されています。
まだ実装されていないか、実装されていないか、モック内でのみ実装されていて、模擬依存関係のテストと実装に実装する必要があることを確認することが重要です。だから、TDD By Exampleと、TDDのやり方の他の例は、実際のリストや精神的なリストについて話をする理由です。依存関係が偽装されたクラス（A）の場合は、モックを書いた後で、あなたはちょうどモックでやったことを（A）または（B）で実装することができます。いずれにせよ、あなたが戻ってそれを行う準備が整うまで、ではなく、を選択したことを追跡しなければなりません。
コードにBが本当に必要になるとすぐにBに依存することをお勧めします。 Aの何もBに依存しない場合は、なぜこの段階で追加しますか？
コードに本当にBが必要な場合は、今すぐ必要なBの機能を実装してみませんか？
論理がない場合はもちろん、Bではなくコード内にダミーオブジェクトを使用することもできます。そうでなければ、私はBの実装を開始するでしょう。