を組み合わせる可能性の重複：
Using IoC for Unit Testingユニットテスト（モック）とDependecy注入フレームワーク
私はユニットテストおよび/または依存性の注入されている方法を理解する問題を持っていると思いますワーキング。私はユニットテストのためにNUnitとRhino Mocksを使い、Dependency Incection FrameworkとしてNinjectを使っています。一般的に、私はそれらの2つが完璧にフィットしますが、どういうわけか、それはちょっと複雑になり、理解するのが難しいようです。
（私は自転車に乗って、それを清潔に保つために良い例を作りようとします）。 DI /ユニットテストなし
1）：
DIとの単体テスト知らず、私のコードは、そのように見えただろう - と私は幸せになるだろう：
public class Person
{
public void Travel()
{
Bike bike = new Bike();
bike.Ride();
}
}
public class Bike
{
public void Ride()
{
Console.WriteLine("Riding a Bike");
}
}
私に乗るためにnew Person().Travel();
2）DIで：
私はその緊密な結合をしたくないので、私はインターフェイスとNinjectModuleを必要と私はちょうど必要があるだろう自転車！私はいくつかのオーバーヘッドを持っていますが、コードが読みやすく分かりやすい限り、それは問題ありません。私はちょうどバイククラスは変更されません、修正Personクラスのコードを渡します：
public class Person
{
IKernel kernel = new StandardKernel(new TransportationModule());
public void Travel()
{
ITransportation transportation = kernel.Get<ITransportation>();
transportation.Ride();
}
}
私はまだちょうどで私の自転車に乗ることができます：new Person().Travel();
3）のユニットテストを考慮すると（なしDI）：
ライドメソッドが正しく呼び出されているかどうかを確認するには、モックが必要です。私の知る限りでは、インターフェイスを注入するために、一般に2つの方法があります：コンストラクタインジェクションおよびセッター注入。 でクラスをnew Person(new Bike()).Travel();
4）DIとし、ユニット・テスト
の準備：この時間
public class Person
{
ITransportation transportation;
public person(ITransportation transportation)
{
this.transportation = transportation;
}
public void Travel()
{
transportation.Ride();
}
}
、私は自転車を渡すためにニートになります。私は、たとえばコンストラクタ・インジェクションを選択します3.単体テスト（DIなし）を検討するは変更なしで仕事をしますが、new Person(kernel.Get<ITransportation>());に電話する必要があります。それを介して、私はDIからの利益を失っているように感じます。Personクラスは、何の繋がりもなく、交通がどのようなクラスのクラスであるかを知る必要はありません。また、このフォームには例2の可読性があまりないと思います。
これはどのように行われますか？それとも、他にも依存性注入と単体テスト（そして模擬）の可能性をよりエレガントに達成する方法がありますか？
（戻ってみると、その例は本当に悪いと思われます。誰もが今乗っている輸送機器の種類を知っているはずです...）
依存性注入（DI）と制御反転（IoC）の定義について混乱していると思います。あなたは3番目の数字です*はDIを実装しています（あなたはコンストラクタに依存を移動しました）、2番目の図はIoC（Ninject）コンテナを使用して依存関係を解決しています。 –
zapthedingbatが正しいです。 3番目の例ではDIを実行していますが、DIコンテナは使用しないでください。これは問題ありません。 DIコンテナは、DIを実行するときはオプションです。 – Steven
例 "2" DIは使用しませんが、「サービスロケータ」は... –