單元測試私有方法似乎使整個解決方案更容易

Question

讓我們假設有一個實用程序類（無數據）與一個複雜（如在，難以測試）公共方法。它使用隨機數生成，返回大量數據和有趣的東西。但是，如果您使用小型私有方法實現它，則每個私有方法都將很容易測試，因此整個事情將更容易測試。從應用的角度來看，只有大的方法需要公開，而另一個應該是私人的。然而，測試私有方法會使測試更容易。我應該如何處理這個問題？

Answer 1

無論你是否應該將你的方法作爲一個單獨的黑箱算法，其子部分不可測試，或試圖將盡可能多的責任儘可能地分離出來，都是非常具有情境性的。

您可能有可能會被重複使用的子部分，在這種情況下，最好將它們排除。您可能有與其他層或硬件交談的子部分 - 同樣的事情。

這一切都取決於這些小的子方法做什麼，很難說沒有上下文。

Answer 2

有時產生隨機數字，返回大數組和其他有趣的東西意味着單個工具類負責多個事物，這意味着應該有更多的類來代替。單一課程中的高複雜性（單一方法！）有時是不良設計的標誌。但是，從來沒有一條金科玉律可以遵循。

Answer 3

只有測試一個類的公共API有一個非常強烈的論據。它使重構代碼變得容易得多，因爲除非您更改方法簽名，否則單元測試不需要更改，他們將驗證您的更改沒有破壞任何內容。

有人說有時候測試私有方法是有意義的（儘管這可能是例外 - 而不是規則）。有些測試框架（例如MSTest）允許您爲此目的訪問私有成員，而另一些（例如nUnit）則不會因爲他們認爲您不應該這樣做（在.Net的情況下，它並不需要太多儘管寫你自己的反射類/方法給你訪問）。

如果您決定測試您的私有方法，請確保您也測試完整的公共方法，因爲您需要公開測試來驗證您以後的重構，如上所述。

Answer 4

需要測試私有方法應該是一個警告標誌。這不是解決您的大而複雜的方法。將功能提取到更小的類中是解決方案，簡化單個Responsibility Principle（SRP）。 SRP指出，一個班級應該只做一件事。

隨機數字生成，數組處理和有趣的東西至少是三個獨立的東西，應該分開完成。

Answer 5

測試私人會員將總是讓你的測試變得脆弱。當你測試私有方法時，你的測試依賴於可以並且經常改變的實現細節。您之所以提供私密性是因爲您希望能夠在不影響其他軟件的情況下對其進行更改。猜猜看：如果你暴露了你的私人物品，即使它只使用反射「黑魔法」，你也會公開它們，因爲你的測試也是你的軟件的一部分。

如果你覺得你必須測試的實施細則，是否因爲你的公共API確實太多，還是因爲私有方法是如此的重要，你應該重構你的代碼和你的私有成員提取物作爲公開課和測試那些。記住，因爲你的測試也是軟件的一部分，所以他們應該對他們使用的代碼有「正常」的訪問權限。

如果你堅持認爲這些（不是）私有方法不能公開，也許是因爲害怕允許外部用戶/代碼訪問它們，你可以通過讓它們訪問這些類來限制這些類的內部（在C＃）或程序包專用（使用Java），並讓代碼的內部對您的測試可見。

無論哪種方式，這聽起來你的代碼應該不被測試或應該公開（更多）。