2012-08-02 71 views
2

雖然重構了一些舊的遺留代碼,但我儘可能地應用了單一責任原則,所以我最終得到了許多隻有一個目的的類。這很好,但是當我試圖爲這些新類編寫單元測試時出現問題。有些課程很難測試,因爲測試很難建立。我需要創建4-5個模擬/存根來編寫一個測試用例,如果我想覆蓋所有的代碼,我需要編寫幾個測試用例,所以這只是一個痛苦的屁股。SRP讓類很難測試

難以建立測試(因爲它取決於許多其他類)是否有代碼味道?你如何解決這個問題?

+3

我想你將需要發佈一些代碼......至少有一個示例類。對我來說,你有一個凝聚力問題,而不是一個SRP問題。或者你的SRP太過分了,你的課程變得太專業了。 – 2012-08-02 19:58:55

回答

3

這裏是Uncle Bob says about SRP

一個班級應該有一個且只有一個變化的理由。

請注意,它沒有說「一個班級只做一件事,只有一件事。」換句話說,對於一個班級來說,如果除了其中一項責任是不變的,或者他們都會一起改變,那麼對於一個班級來說,承擔多項責任是完全有效的。

在他的書中Agile Patterns, Principles, and Practices,Bob大叔說:

在SRP的背景下,我們定義了一個責任是變革(117)的一個原因。

和:

如果,另一方面,應用程序不是在導致[多個]職責,在不同的時間改變的方式改變,沒有必要將它們分開。事實上,分離它們會產生不必要的複雜性。 (118)

也就是說,一個有太多合作者的類是一種氣味,應該仔細檢查。

0
  • 你不需要所有的代碼覆蓋,使用常識
  • 隨着小班它應該很容易判斷不變,所以用斷言填充它們,讓代碼測試本身
  • 分裂您的系統進入層並確定在那裏你可以插上模擬刺激把那些聲稱工作和驗證輸出