訪問器必須進行單元測試嗎？

Question

對於除了其他方法之外還有幾個setter和getter的類，在編寫訪問器的單元測試時節省時間是否合理？考慮到在測試接口的其餘部分時會調用它們？

Answer 1

絕對如此。單元測試的想法是確保更改不會以未知的方式影響行爲。您可以通過不寫入getFoo()的測試節省一些時間。如果您將Foo的類型更改爲稍微複雜一點，那麼您可能很容易忘記測試訪問者。如果你在質疑你是否應該寫一個測試，你最好寫它。恕我直言，如果你想跳過爲方法添加測試，你可能想問自己，如果方法是必要的或不是。爲了充分披露，我是那些人之一，只有在證明有必要時才增加二傳手或吸氣劑。您會驚訝於在施工後您真的不需要訪問特定的成員，或者您只想訪問真正依賴於成員的計算結果。但我離題了。

一個好的口頭禪是總是添加測試。如果你認爲你不需要一個，因爲這個方法是微不足道的，請考慮刪除該方法。我意識到，通常的建議是，跳過「微不足道」方法的測試是可以的，但是您必須問問自己該方法是否必要。如果你跳過這個測試，你就是說這個方法總會讓總是變得微不足道。請記住，單元測試也可用作意向文件和合同提供的文件。因此，一個微不足道的方法測試表明該方法的確意味着微不足道。

Answer 2

我只會單元測試他們，如果他們做的不止是設置或返回一個變量。在某些時候，你需要相信編譯器會爲你生成正確的程序。

Answer 3

我喜歡爲它們進行單元測試。如果訪問者除了簡單地返回一個字段之外還有其他工作，那麼這些代碼將被正確地測試。

即使給定的存取器除了返回一個字段之外沒有其他任何操作，它可能稍後會被修改來做額外的事情。

此外，這是一個簡單的方法來增加正在運行的測試的數量，許多管理者都喜歡。

Answer 4

如果您的IDE生成並管理成員訪問器的修改---您不會做任何特殊的事情---那麼測試它們確實不重要;類型將匹配，命名將由模板等。

Answer 5

我的測試標準是每一段包含條件邏輯（while，if，for等）的代碼都要被測試。如果訪問器是簡單的getter/setter，我會說測試它們是在浪費你的時間。

Answer 6

我認爲節省時間是合理的，不要寫出你認爲不會特別有用的單元測試。

雖然100％的測試覆蓋率是一個令人欽佩的理想，但在某些時候，如果您花時間編寫測試並不值得您從中獲益，那麼您會遇到收益遞減的情況。

如果您發現某些情況下，您可以隨時返回並添加更多的單元測試，從而確定它們會有用。

Answer 7

我想大多數人會說測試它們是浪費你的時間。在99％的情況下是這樣。如果在訪問器中存在一個錯誤，而其餘的單元測試不會間接捕獲它，那麼我會開始質疑爲什麼該屬性存在。

在另一方面，檢測的訪問需要較少的打字說問這個問題:)

我個人對其進行測試。但對我而言，這是一個灰色地帶，只要他們有足夠的關於課堂功能的覆蓋範圍，我就不會迫使我的小組中的其他人進行測試。

Answer 8

通常當我考慮寫單元測試我問自己如下：

1. 是對的getter/setter的DAL（數據訪問層）訪問什麼？

如果是這樣，那麼我會包括一個單元測試。以防萬一，因爲如果在將來的某個時候你決定實施延遲加載，或者比簡單的get/set更高級的東西，那麼你需要確保這個工作正常。

1. getter/setter會拋出一個異常是否可能？

獲得者的最佳實踐是不允許他們拋出異常。二傳手是另一回事。但是，無論哪種方式，如果您決定某個屬性可能會拋出異常，那麼爲該屬性編寫單元測試，既可以成功訪問，也可以有目的地生成異常。

除此之外，我不會打擾，正如Dan指出的那樣：「在某些時候，您需要相信編譯器會爲您生成正確的程序。」

Answer 9

我們公司有兩種人和意見。我傾向於並非專門測試它們，因爲它們通常

• 在另一個測試的情況下測試（自動生成如還有其他一些代碼，利用這些訪問的
• 不包含任何代碼這可能會破壞

也有例外，但：

• 當他們不是簡單的摹enerated「干將」和「二傳手
• 當他們是，這只是提供給其他用戶，並在您目前正處於

這兩種情況下威力使得環境沒有真正測試的一個重要API的一部分我來測試他們。第一個比第二個多。

Answer 10

沒有冷靜的方式！ 浪費時間！

即使鮑勃馬丁See SO podcast 41，敏捷的祖父說不。

Answer 11

您不必爲不包含邏輯的屬性編寫測試。

測試簡單屬性的唯一解釋是提高測試覆蓋率 - 但它很愚蠢。