單元測試IoC註冊？

Question

你應該單元測試將組件註冊到你的IoC容器的代碼嗎？

如果是這樣，怎麼樣？

Answer 1

由於你的組件可能有它們自己的依賴關係或執行一些初始化，所以我會用UT來覆蓋這個場景。

喜歡的東西

iocContainer.Register(typeof(MyService1)); 
service = iocContainer.Get(typeof(MyService)); 
Debug.AssertNotNull(service); 

Answer 2

在春天，你可以簡單地加載應用程序上下文沒有任何斷言單元測試。它實際上是一個與自動構建相結合的相當有用的測試，因爲在加載完整上下文時，spring會抱怨很多問題。

Answer 3

我在一個ASP.NET MVC項目中使用了Windsor，我寫了一個簡單的測試來驗證所有的控制器都可以被實例化（即它們的依賴關係可以被解析）。

我對網站的每個配置（例如「開發」，「測試」，「someProductionSite」等）進行測試，其中我創建了我的Windsor容器，並通過所有非抽象實現的IController，檢查我是否可以解析每個實例。

由於控制器工廠是進入應用程序的唯一入口點，將導致container.Resolve（...），我100％肯定所有配置都是有效的。

一般來說，我發現寫作測試作爲斷言關於整個系統是非常有用和有價值的。

E.g.我還聲稱所有的控制器操作都是虛擬的，這是必需的，因爲我使用Castle的自動事務管理來將控制器操作與事務進行環繞。

Answer 4

@aku，@krosenvold和@mookid爲測試依賴關係的配置是否正確提供了一個引人注目的參數。
我不認爲這是單元雖然測試。
你在測試什麼？你不是試圖單元測試容器本身（可能這不是你編寫或維護的代碼）。
您試圖測試的是，可以創建特定類型的所有依賴關係，並且可以解析該類型。這聽起來像是一個非常有用的系統測試或集成測試，可以在您的持續集成環境中使用。
因此，一旦你有通過單元測試的二進制文件，你可以創建容器並在一臺鏡像你的生產環境的機器上運行容器的設置，並測試容器應該能夠解析的每種類型被創建並且它們的所有依賴可以被實例化。
這將是一個很好的運行在一個新的虛擬機，你已經應用了你的最新安裝程序。

Answer 5

它可能很有用，因爲一些依賴注入框架（如Unity）具有奇怪的規則來選擇要調用的構造函數。我肯定會推薦單元測試，以確保您的類型的註冊和創建成功。

Answer 6

它讓我感覺不對，讓IoC容器在我的測試項目中運行。我還注意到，大部分由依賴沒有解決的錯誤都是由順序依賴解決的，這很難測試，而且不是我想做單元測試的東西。

通常我在我的類的初始化例程中使用Debug.Assert語句。這給了我一個IoC相關錯誤的預警系統，還有助於更好地在我的代碼中指定依賴關係。

Answer 7

我如何處理 IoC容器，是我首先使用沒有Guice的TDD生成某些功能的類（這些是單元測試）。然後我用Guice爲這個特性創建一個集成測試。此時IoC配置（Guice模塊）不完整，因此集成測試將失敗。使用TDD，我將逐步添加IoC配置，直到集成測試通過。除非需要通過測試，否則我不會添加任何@Inject註釋，配置行或範圍聲明。因此，我將進行集成（或驗收）測試，確保IoC配置是正確且完整的。

同樣的方法應該與任何IoC容器或其他系統，其配置是如此複雜，它可能會破壞工作 - 除非它是需要通過測試不寫任何配置。

Answer 8

回答這個問題，專門爲Castle Windsor：

Castle Windsor: How to test that all registered components are resolvable?