使用代碼主體中聲明的具體類的單元測試類

Question

很簡單，我想找出的是，有沒有辦法對這段代碼進行干凈的單元測試？ 我可以實例化它並運行一些斷言，但我的意思是實際的單元測試，我將模擬服務 object 以刪除正在測試的 class 的任何依賴關系，實際上讓它只測試這個 class 的服務（而不是它的依賴服務）。

public class Foo{

    public SomeResult DoSomething(){
        var service = new ConcreteService();
        var foo = service.Execute();
        return foo;
    }

}

我的正常方法是不在我的代碼體中創建這種類型的 object，但是鑒於無法更改的情況，我有哪些單元測試選項？

Answer 1

鑒於約束（您無法修改/重新編譯該代碼），恐怕除了“集成測試”之外您無能為力 - 真正的依賴關系，緩慢的測試。

在方法中實例化一個依賴，而不是接受它作為一個 ctor 或方法參數會使事情變得困難。

正如 Ethan 所說，有痣（但對我個人而言，它似乎並不正確）。 我更喜歡設計更改，而不是幫助我掩蓋設計問題的框架。

Answer 2

如果 service.Execute() 是虛擬的，那么大多數 mocking 框架都支持這一點。 我個人使用Rhino.Mocks 。

請參閱此問題，其中詳細介紹了在非接口上使用 Mocking 框架的功能，並討論了 mocking 框架攔截虛擬調用的功能。

如果它不是虛擬的，並且您無法更改它，那么您可以使用Moles 。 上面提到的帖子還提到了使用TypeMock的能力，我個人沒有使用過。

微軟研究網站上對 Moles 的描述：

Moles 是一個輕量級的框架，用於在 .NET 中基於委托的測試存根和彎路。 Moles 可用於繞過任何 .NET 方法，包括密封類型中的非虛擬/靜態方法。

Answer 3

我知道您提到這將是您無法更改的情況的一個示例，但我會努力重構 class 以便可以將 ConcreteService 作為依賴項注入。 重構是嘗試解決糟糕設計的一種更簡單的方法。 從您發布的內容來看，我認為您沒有理由不能這樣做。

編輯： FWIW，我同意@Gishu。 如果您絕對不能修改 class，例如您不擁有它並且您沒有能力修改它，那么集成測試是最好的方法。 然而，如果你能看到代碼和它在做什么，我支持我之前所說的，你沒有理由不重構。