TDDに従うことは必然的にDIにつながりますか？

テスト駆動開発（TDD）、依存性注入（DI）、および制御の反転（IoC）をすべて同時に行うことを学びました。TDDを使用してコードを記述するとき、クラスのコンストラクターで常にDIを使用します。これは、TDDをどのように学んだかによるものなのか、それともTDDの自然な副作用なのか疑問に思っています。

だから私の質問は次のとおりです：TDDプリンシパルに従って、外部サービスに依存しない単体テストを書くことは必然的にDIにつながりますか？

データベースや外部サービスに依存しないTDDの作成と単体テストの作成は、必然的にDIにつながりますか？

DIの広い定義については、はい。クラスはバキュームには存在しないため、依存関係を何らかの形で満たす必要があります。値を提供するだけで十分な場合もあります。コンストラクターでモックを提供する必要がある場合があります。時々IoCコンテナ経由。場合によっては、プライベートテストアクセサーを使用します。すべてのテストをクラスに注入するので、単独で動作します。

すでにDIについて知っているが、そのポイントを見たことがない人にとって、ユニットテストはほとんど常にDIの使用につながると思います。

あなたがいる場合はありません DIについて知っていると、ユニットテストを書くしようとしている、一部の人々は自然にDIを改革し、一部はイライラし、最終的に研究を通じてDIを発見しますが、それは単に誰かに発生しませんどのように頻繁に驚かれると思いしまいます単体テストを簡単にするためにソフトウェアを設計するより良い方法があるかもしれません。それらの人々は、単体テストを扱いにくいと断念し、あきらめます。

ユニットテストはDIにつながります（疎結合ユニットの作成を強制するため）。TDDは、「逐語的」単体テストの代わりに、レイヤーごとにテストを作成するためにも使用できるため、必ずしもそうではありません。この記事をご覧ください

http://stephenwalther.com/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx

違いの説明については。

はい、いいえ：TDDはよく構造化されたコードを書くことにつながり、それ自体がDIにつながります。

つまり、TDDは通常、カプセル化、SRP、および再利用性に関して正しい方法で送信します。コードをテストするだけでなく、それらのテストを使用してより良い設計を具体化することも重要です。オブジェクトが独自の依存関係を作成する場合、それは特定のアプリケーション内の特定のコンテキスト内に存在し、アプリケーションに組み込まれる可能性が高くなります。DIは、テストの観点からだけでなく、コード品質の観点からも良いことです。

他の回答ですでに指摘したように、TDDはユニットテストを必要としません。TDDを実行しながら、統合/機能テストを作成することもできます。TDDを適用するいくつかの方法のうち、単体テストの作成は「あなたが作るまで偽造する」方法です（詳細については、Kent Beckの本を参照してください）。

「TDDが必然的にDIにつながる」ことに関しては、間違いなくそうではありません。単体テストを記述するときに必要なのは、テスト対象のユニットを外部依存関係の実装から分離することです。そして、これはDIの有無にかかわらず簡単に実行できます。最善の方法は、おそらく、適切な分離/モッキングツールを使用することです。