通常，當使用依賴注入時，單元（和其他）測試負責創建/模擬被測系統的相關性並注入它們。向測試注入依賴關係
但是，有時測試本身具有依賴性，或者需要將依賴關係注入到SUT中，而它本身不能創建。例如，當測試與數據庫交互的類時，測試需要知道連接字符串和目錄名等，這些不能被硬編碼，因爲對於運行測試的每個人來說它們不一定相同。
那麼，你會如何建議測試找出這些設置？做一些xUnit風格的測試框架提供了一種給測試用具提供依賴性的方法嗎？在運行所有測試之前，測試類是否應該具有靜態屬性？該測試是否應該忽略DI實踐並從全球某個地方去獲取依賴關係？其他建議？
當你使用單元測試框架做集成測試，你真的沒有一個DI或單元測試的問題。
你有什麼是集成測試是利用高功率的單元測試框架。
因爲它們是集成測試，他們是從單元測試的種類不同。 「獨立性」不再是真正的數字。
獲得集成測試設置，從用戶而異，最好的辦法是讓他們以同樣的方式最終應用會得到他們。如果你使用Java，你可能有一個屬性文件。在Python中，我們有用於集成測試的特殊Django設置文件。
完全自動化測試的原理：您應該能夠從源代碼控制庫中下載所有源代碼，並運行測試。考慮到環境（機器）具有正確的安裝基礎（即編譯器，測試框架，數據庫引擎，如果相關等），測試負責在執行測試用例之前設置其Fixture。
這意味着，對於數據庫，試驗應該
後如果再次刪除數據庫，出於某種原因，你不能這麼做，你唯一能做的就是在你的源代碼控制系統中有一個配置文件，它包含你的測試中所有機器的特定機器條目invironment;例如對於機器Tst1連接字符串是一個值，但對於Tst2這是另一個值。
這會變得非常惡劣真的很快，所以它更容易有測試負責夾具的安裝和拆卸，因爲這意味着他們可以簡單地使用現場產生的硬編碼值，或者價值觀。
這真的沒有任何關係與DI ...
DI戰鬥與依賴條件的複雜性，而您的單元測試必須是大部分時間非常簡單。典型的單元測試將檢查一個孤立類的一個孤立的方面。而不是你創建mock的所有依賴，並且（通常）通過CUT（Class Under Test）構造函數注入它們。這裏通常不需要DI框架。
但是。顯然，一些更高級別的測試可能仍然需要非模仿依賴。例如，您希望對大量數據進行測試，並且不想創建特殊的假數據源，以便將其保存在真實的數據庫中（也可以使用該數據執行一些UI測試）。在這種情況下，我仍然會盡量保持儘可能簡單，在課堂設置/測試設置方法中初始化測試。
你看，你需要小心點。無論您何時進行大型複雜測試，您都可以：
等等