OOP設計 - 私人修改器

Question

我以爲我知道什麼時候應該使用private關鍵字。封裝是這個原因，因此我儘可能地使所有方法都是私有的。

我剛剛在測試中寫了一篇文章，並被告知在我的私有方法中使用反射進行測試並且它是糟糕的代碼設計是一個壞主意。爲什麼會出現這種情況，我的密鑰隱藏/封裝是一件好事，應該不要測試，因爲這實際上是我公共代碼所依賴的關鍵所在？

Answer 1

好的測試嘗試實現高代碼路徑覆蓋率，所以是的，測試私有方法是件好事。但爲什麼你用反射直接打電話給他們呢？ 這些方法是私密的這一事實通常表明存在使用它們的公共/受保護方法。因此，公共方法的測試意味着私人方法的測試。

Answer 2

由於私有方法不是您的公共接口的一部分，您可以隨時隨意更改它們。如果你直接測試你的私有方法，這些改變將會破壞測試。這就是爲什麼你應該只測試你的代碼的公共接口，而不是私有方法。

@西蒙也提出了一個很好的觀點。如果您遵循嚴格的測試優先方法，那麼您只會編寫公共方法。私有方法將主要通過重構創建（如果不是唯一的話）。

Answer 3

封裝的要點是它可以讓你改變內部行爲而不破壞別人的代碼（也就是說你重構3個私有方法到1）。如果你測試這些內部方法，如果你改變它們，你將會中斷測試。此外，現在你在改變它們之前會考慮三次，限制你的自我改進。

如果您想測試您的方法是否正確，請測試它們對公共方法造成的影響。

Answer 4

一個好的設計方法是從公開的方法開始並對其進行很好的測試。在某些時候，你的公共方法將會變得越來越大，這就是重構的時候了。 使用重構來分解和提取私有方法。這將導致一個很好的私有方法覆蓋，因爲它們包含的代碼曾經是您的單元測試涵蓋的公共方法。反思可能對您很容易使用，但想想您的同事將接管您的代碼，他們可能不如您;）

Answer 5

通常使用單元測試來測試類的公共接口。 許多聰明人不建議測試私人方法。 我同意這一點，因爲所有功能的測試是很多無聊的工作。 爲了我的經驗，對公共接口的良好覆蓋足以構成可靠的軟件。

Answer 6

請參閱Bill Venners的Testing Private Methods with JUnit and SuiteRunner。