應該JUnit測試javadocced？

15

如果測試的目的很明顯，我不打算記錄它。

如果它不明顯，因爲它處理一些不明確的情況 - 或者如果我想參考一個特定的錯誤，例如 - 在那 case我會添加文檔。雖然我沒有記錄異常拋出等 - 只是對方法的快速總結。這很少發生。我更可能爲多個測試中使用的助手方法添加文檔。

來源

2009-11-26 16:19:35

+0

我同意你的意見。我討厭看到單元測試不清楚他們正在測試什麼。代碼隨着時間而改變，原始原因可能不明顯。 –

+1

我寧願在每個assertFoo語句中看到一個說明字符串。 –

10

我在javadocing測試用例中找不到任何值。我只是將方法名稱描述得足以知道測試的目的。

在Ruby中，我知道有些工具可以從測試名稱創建文檔，但是我沒有在Java中看到過其中的一個。

來源

2009-11-26 16:10:50

1

我不明白爲什麼您應該將測試用例與您的生產代碼關於註釋的處理方式有所不同。

來源

2009-11-26 16:12:41 JesperE

+0

但是正如上面提到的Kaleb，如果名稱足夠冗長，那不就是多餘的嗎？ – Jim

+0

正確命名的標識符不能替代評論。 – JesperE

3

無論javadoc與否，我認爲單元測試一定要記錄下來。在沒有正式規範的情況下，單元測試最接近於定義代碼的預期行爲。通過記錄測試用例，您將會向讀者明確測試的內容以及測試的原因。

來源

2009-11-26 16:13:15 omerkudat

+0

完全同意你的看法。我也一樣。我將該方法命名爲test [MethodUnderTest] _Should [ExpectedBehavior] _When [Scenario]。所以這就是文檔本身。加上我應該包含在產品文檔中的javadoc行爲。 –

1

我認爲javadoc測試通過的條件很有價值。

來源

2009-11-26 16:24:02

2

在考慮作爲文檔的測試時，「記錄文檔」沒有多大意義。每個測試的名稱本身應該已經描述了測試的目的是什麼 - 該測試指定的行爲是什麼。

使用長的描述性名稱進行測試，並儘可能保持測試代碼的可讀性。

例如看看測試案例in this project。通過查看測試的名稱和測試代碼，他們中的任何一個是否做了一些並不明顯的事情？

只有在極少數情況下，當測試代碼不清晰時，測試中需要註釋。例如，如果您正在測試多線程代碼，並且測試代碼會執行奇怪的操作，以確保測試代碼以正確的順序運行。但即使在這些情況下，a comment is an apology也不會寫出更清晰的測試代碼。

來源

2009-11-26 16:30:12

0

地獄是啊。即使它只是...

創建訂單，編輯訂單，保存，加載&檢查它。

如果它是一個非常簡單的測試，那麼也許不是。

我發現，隨着代碼的變化，有時測試的原因並不像以前那樣明顯。

來源

2009-11-26 16:30:42

0

也許你可能會找到一個對你的代碼不完全熟悉的人，來告訴你一些關於你的測試是否易於理解的快速反饋。

在我工作的公司，我們嘗試給我們的測試描述性名稱和文檔複雜性，但通常很難在第一稿中得到這個「正確」，因爲對開發人員來說顯而易見的事情並不總是很明顯給他人。

測試被視爲代碼並作爲同行評審過程的一部分提交，所以我們的（小）團隊可以評論測試是否易於理解。

如果測試有點令人困惑，我們可以相應地更新名稱或文檔，我們會更好地評估什麼是有效的，哪些沒有。

來源

2009-11-26 16:52:26 analogsilence

1

建議代碼註釋是反模式是異端嗎？我同意上述答案，理想情況下，您的代碼足以描述性地依賴於沒有評論的內容。如果您處於（企業）環境中，人們傾向於更新代碼而不更新註釋，則註釋會變得具有誤導性，這一點尤其如此。

來源

2009-11-30 21:34:48

應該JUnit測試javadocced？

回答

相關問題