2017-09-23 54 views
1

最近,我在編寫測試用例的同時編寫遺留代碼的單元測試用例,我提出了一個問題。這是一個很好的做法,將私有方法更改爲公開單元測試用例

由於我正在編寫單元測試用例而不是集成測試。問題是私人方法。在我們的代碼中,公共方法依賴於5 私有方法

對於單元測試用例,我需要僞造私有方法的實現,但由於方法是私有的,我不能這樣做。 因爲MOQ嘲諷框架不支持私有方法的嘲諷功能。甚至我無法編寫私有方法的測試用例。

可能的方法,我想

移動在不同的類中的所有私有方法。並讓它們公開並創建這個類的接口。通過這種方式,我可以在運行時給出假實現,因爲現在我們有了該類的接口。

但是這種方法的問題是我需要將這個私有方法公開爲單元測試用例。因此公開這是一個很好的做法。

回答

1

當我開始看到自己寫很多私有方法時,我會做普通的拆分類。但是,你有兩個選擇:

  1. 完全只測試公共接口。當然,您應該涵蓋您的私人方法。

    • 對所有功能保持在一起有意義的類有效。也就是說,這個班級已經很好地抽象出來,並且具有單一職責。
    • 如果在課堂上保留這些私人方法意味着更多的嘲弄和設置是每個案例都需要的,這會是一種痛苦。
  2. 你可以讓你的私人方法internal並註明您的測試項目爲friend assembly。然後他們可以直接進行單元測試。

    • 當分裂班級沒有意義時,這可以再次生效。
    • 當您有一堆使用一種公共方法調用的私有方法時,這比測試公共接口具有優勢。如果您想測試其中一種私有方法的一部分,則不必設置公共方法所需的所有內容。這也使得事情更易於理解和調試。
  3. 你已經想到的解決方案只是分裂了類。有時候代碼很難測試,表明裏面有一個類正在嘗試突破。

    • 如果您可以將部分或全部私人功能分組到一個命名實體中,您可能需要將其分開。特別是如果您有其他情況下可能可以重用這樣的課程。
    • 如果您的原始類具有較大的依賴項列表,並且可以使用此選項減少它,這也是一個不錯的選擇。
+0

起初,我想一起去點1.但是,在這種方法的問題是,它是不容易掩蓋內部的私有方法,方法包含複雜的邏輯,因此單元測試的情況下會成爲所有路徑效率低下。 –

相關問題