單元測試私有方法是一種好的做法嗎？

通常只有公共接口應該被測試。

不過，我已經發現了複雜的計算，它調用噸不同的私有方法時，更容易進行單元測試第一的私有方法，然後進行了公共接口方法的簡單測試。

作爲例子，讓我們假設你有一個音頻播放器，你有功能：

void play(){ ... } 
void pause(){ ... } 
void seek(time t) 
{ 
    //All Private methods 
    checkIfValidTimeRange(...); 
    moveToFilePos(...);  
    fillBuffers(...);  
}

通常我會編寫單元測試：checkIfValidTimeRange(...)，moveToFilePos(...)，fillBuffers(...)。

但我不確定如果這樣做是好的做法。

來源

2012-02-08 Anton

做什麼是有道理的..如果你的私人方法很複雜，爲什麼不測試它們？ – 2012-02-08 23:02:16

這是不是一個好的做法（但這並不意味着你不應該這樣做），如果可能的話，你想避免它。測試私人方法通常意味着您的design could be better。讓我們快速瀏覽一下您的播放器例如：

moveToFilePos：聽起來更像的東西做的I \ O操作的責任，而不是音樂播放器的
fillBuffers：更多的是內存管理的工作，而不是音樂播放器
checkIfValidTimeRange：再次，也許可以被移出玩家的範圍，一些簡單的驗證類（好像這一個可能是藏漢其他地方有用）

此刻你音樂播放器沒有I/O，內存管理和其他什麼。這一切是否真的在其職責範圍內？

來源

2012-02-08 23:14:26

這個例子只是爲了展示一個簡單的演示。但讓我說我創建MusicFileIO類和MusicFileBuffer類來檢查。我應該讓這些課程在音樂播放器課程內部進行嗎？（因爲我不想暴露他們的存在給用戶）。但是，如果我讓他們成爲內部和私人的，我是否一開始就不回到我的問題？ – Anton 2012-02-09 00:00:31

@安頓：只要他們得到適當的測試，那麼這些新課程所暴露的內容是多麼的無關緊要。我們正在從這個真正的問題中走出來 - 測試私有方法並不壞，因爲*方法是私有方法*，但是因爲它通常意味着*糟糕的設計*。當您更改'fillBuffer'（*「現在緩衝區來自其他地方！」 - 匿名客戶端*）時，您不希望發現自己處於某種情況下。現在沒什麼意義了，以後再也沒有意義了。 – 2012-02-09 14:36:25

仍然。未經測試的代碼變成「遺留」代碼（參見[使用遺留代碼有效工作]（http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052））。因此，如果公共接口的真實複雜性是完全覆蓋它（例如門面）是不可行的，那麼測試私有方法是imho是兩個惡意中較小的一個。 – Txangel 2013-05-31 13:14:14

恕我直言，這是一個非常不錯的主意，我做這一切的時候。我通常會創建一個輔助類，這使得私有方法accessable並測試它..

通常它更容易測試私有方法，因爲他們做的非常具體的東西。另一方面，你可能有一個很大的公開方法，這有點難以測試。所以它肯定簡化了單元測試。

來源

2012-02-08 23:01:52 duedl0r

如果你的私有方法十分複雜，需要測試，你可能錯過了一些類，其中的私有方法是把公共。

你當然可以測試私有方法，但你應該把需要做它作爲一個提示有什麼不對您的設計。

來源

2012-02-08 23:07:21

你的代碼庫的哪個部分是你的私有方法依賴？如果有人改變了你所依靠的方法之一，從而打破了你的方法，是否值得了解它？測試不僅用於檢查您的方法是否應該如其行爲，而且還用於檢查代碼庫其他部分中的更改是否不會破壞您的方法。

所以，除非你的方法只使用語言的基本結構，測試一下吧！

來源

2012-02-09 00:05:58

單元測試私有方法是一種好的做法嗎？

回答

相關問題