名前付きコンポーネントを使用してこのIoC登録をユニットテストする方法は？ （Autofac）

Question

複雑な作成コードの一部をIoCコンテナAutofacを使って変換するのを見ています。私はTDDを大変信じていますので、モジュール設定の単体テストを書いています。

ほとんどの機能は、テストするのが非常に簡単です。

var obj = container.Resolve<IThing>(); 
Assert.IsInstanceOfType(obj, typeof(ThingImplementer)); 

しかし、私たちには同じインタフェースの複数の実装者があり、異なる実装者が異なる具体的なクラスに渡されるケースがいくつかあります。私はこれを名前付き登録を使用して解決しました。私が把握することはできませんどのような

builder.RegisterType<ThingImplementer>().Named<IThing>("Implementer1"); 
builder.RegisterType<OtherImplementer>().Named<IThing>("Implementer2"); 
builder.Register(c => new Foo(c.ResolveNamed<IThing>("Implementer1"))).As<IFoo>(); 

はfooがOtherImplementer ThingImplementerを取得していないことを確実にするためのユニットテストを書くための簡単な方法です。努力する価値があるのか​​どうか、これをカバーする高度な統合テストがありますが、単体テストが行​​うドキュメンテーションやリファクタリングの利点はありません。

ユニットテストを作成しますか？ そうなら、どうですか？

Answer 1

通常、単体テストでコンテナの構成をテストしません。ユニットテスト環境では、コンテナを使用して依存関係を注入することはありません（これは手作業で行います）。これを行う場合は、実際の/生産タイプではなく、擬似オブジェクトを注入します。したがって、コンテナの構成は通常、単体テストでは不明です。

時には、コンテナがアプリケーションのルート型（MVCアプリケーションのコントローラクラスやWebFormsアプリケーションのページクラスなど）を作成できるかどうかをテストすることがあります。コンテナはオブジェクトのグラフをインスタンス化するため、コンテナが正しく構成されているかどうかを確認することができます。しかし、コンテナが正しい実装を返す場合、私は決して興味がありません。ほとんどの場合、アプリケーションルートでアクセス可能な登録済みインターフェイスの実装が1つしかないので、間違っている可能性はほとんどありません。

コンテナの設定をテストする場合は、複雑すぎる可能性があります。アプリケーションの設計を簡素化して、登録を簡単にする必要があります。

Answer 2

ここには何も新しくありません。ただスティーブンのポイントの拡張です。

スティーブンは言うとおり、これは間違いなくユニットテストではありません。おそらくそれを学習テストとして見ることができます。 Ninjectのテストスイートを見てください - それは彼らがどのようにそのようなテストを行うかを示します（しかし彼らはコンテナを書いていることを覚えています）。私はautofacが同様のテストを持っていると仮定します。

あなたは興味深い動作があると感じて、フレークにならないと思うと、それを統合スイートに張り付けることは害ではありません。

外部の事実に関する他の点も非常に有効です。Onion Architecture

という概念を参照してください。