通過設計注意事項簡化測試，同時利用依賴注入

Question

我們幾個月進入一個綠色領域的項目來重新修改我們產品的邏輯層和業務層。通過利用MEF（依賴注入），我們實現了高水平的代碼覆蓋率，並且我相信我們擁有非常穩定的產品。當我們一直在研究一些更復雜的邏輯時，我發現它越來越難以進行單元測試。

我們利用CompositionContainer來查詢這些複雜算法所需的類型。我的單元測試有時難以遵循，因爲必須進行漫長的模擬對象設置過程，恰到好處，以便確認某些情況。我的單元測試通常比我想測試的代碼花費更多的時間來編寫代碼。

我意識到這不僅是依賴注入的一個問題，而且是整個設計的問題。對於我過於複雜的測試來說，缺乏方法設計或缺乏構圖？我已經嘗試了基類分類測試，創建了常用的模擬對象，並確保儘可能地利用容器來緩解這個問題，但是我的測試總是很複雜且難以調試。有什麼提示可以讓你保持簡潔，可讀和有效的測試？

Answer 1

我的主觀視點：

• MEF看起來像一個非常好的插件框架;它的設計不是一個完整的DI框架。如果您不需要活動的可插拔組件，請調查full DI/IoC Container frameworks。 Unity是微軟的替代品。
• 請確保您是而不是正在做Service Locator anti-pattern。儘可能使用接口的構造函數注入。請參閱great post by Mark Seemann和this one by Jimmy Bogard。你所說的「儘可能地利用容器」是一個值得關注的問題 - 很少有班級需要知道關於容器的任何東西什麼。
• 獲得一個非常好的嘲諷/隔離框架並學習如何使用它。我愛Moq。嘗試在被測系統上進行狀態驗證，而不是在模擬上儘可能進行行爲驗證。
• 閱讀The Art of Unit Testing。閱讀有關單元測試的其他書籍和文章。練習TDD。保持學習。
• 閱讀Clean Code並確保您的課程遵循SOLID原則（尤其是Single Responsibility Principle）。冗長的模擬設置是一種代碼味道;你的課程可能做得太多了。高代碼覆蓋率很好，但更好的指標可能是cyclomatic complexity。
• 不要擔心你的單元測試花費的時間比生產代碼要長。然而，像生產代碼那樣對待你的測試，並且在你保持可讀性和可維護性的時候刪除重複。

Answer 2

以下是有關DI和良好的設計實踐（書面測試的代碼而言）一些很好的聯繫，你可能想看看（谷歌技術講座）：

• Clean Code Talks - Don't Look For Things!
• Clean Code Talks - "Global State and Singletons"
• Clean Code Talks - "GuiceBerry"

我發現他們非常有用，有很多關於可測試de的很好的提示標誌。