2010-11-28 31 views
5

我正在尋找將我們的一些複雜創建代碼轉換爲使用IoC容器Autofac,並且因爲我非常信任TDD,所以我正在爲模塊配置編寫單元測試。如何使用命名組件單元測試此IoC註冊? (Autofac)

大部分功能非常容易測試,例如

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>(); 

我無法弄清楚什麼是寫確保富得ThingImplementer而不是OtherImplementer單元測試的簡便方法。我想知道是否值得付出努力,我們的高級集成測試涵蓋了這一點,但他們沒有給出單元測試所做的文檔或重構優勢。

你會爲此寫一個單元測試嗎? 如果是這樣,怎麼樣?

回答

7

您通常不會在單元測試中測試容器的配置。在您的單元測試環境中,您不使用容器來注入任何依賴項(您手動執行此操作),如果要這樣做,則會注入假對象,而不是真實/生產類型。因此,對於單元測試,容器配置通常是未知的。

我有時候會傾向於測試容器是否能夠創建應用程序的根類型(例如MVC應用程序的控制器類或WebForms應用程序的Page類)。因爲容器會實例化一個對象圖,它會給我一個好主意,容器是否配置正確。但是,如果容器返回正確的實現,我從不感興趣。大多數時候,甚至只有一個應用程序根目錄可以訪問的註冊接口的實現,所以它幾乎不會出錯。

如果你想測試你的容器配置,可能它太複雜了,你應該儘量簡化你的應用程序設計,這樣你可以簡化註冊。

2

這裏沒有什麼新東西,只是史蒂文的觀點的延伸。

正如Steven所說,這絕對不是單元測試。你也許可以將其視爲學習測試。看看Ninject測試套件 - 它顯示了他們如何進行這樣的測試(但是請記住他們正在編寫一個Container)。我假設autofac有類似的測試。儘管如此,如果您覺得有趣的行爲並且不會變得脆弱,那麼將其集成到集成套件中並不是壞事。

關於外部事實的另一點也非常有效 - 請參閱Onion Architecture的概念