我有點困惑我應該在單元測試上投入多少。假設我有一個簡單的功能，例如：appendRepeats(StringBuilder strB, char c, int repeats)[此函數會將 char c 重復次數附加到 strB。例如：strB = "hello"c = "h"repeats = 5// resultstrB = "hellohhhhh"]對于這個功能的單元測試，我覺得已經有很多可能性了：AppendRepeats_ZeroRepeats_DontAppendAppendRepeats_NegativeRepeats_DontAppendAppendRepeats_PositiveRepeats_AppendAppendRepeats_NullStrBZeroRepeats_DontAppendAppendRepeats_NullStrBNegativeRepeats_DontAppendAppendRepeats_NullStrBPositiveRepeats_AppendAppendRepeats_EmptyStrBZeroRepeats_DontAppendAppendRepeats_EmptyStrBNegativeRepeats_DontAppendAppendRepeats_EmptyStrBPositiveRepeats_Append等等等等。 strB 可以為 null 或為空或具有值。c 可以為 null 或具有值 repeats 可以為負數、正數或零那似乎已經有 3 * 2 * 3 = 18 個測試方法。如果這些函數還需要測試特殊字符、Integer.MIN_VALUE、Integer.MAX_VALUE 等，那么其他函數可能會更多。我的停止線應該是什么？出于我自己的程序的目的，我是否應該假設：strB 只能為空或具有值 c 具有值 repeats 只能為空或正抱歉打擾了。只是真的很困惑我應該如何偏執地進行一般的單元測試。我應該留在我的假設范圍內還是那是不好的做法，我應該為每個潛在案例都有一個方法，在這種情況下，單元測試方法的數量將以指數方式快速擴展。
4 回答
開滿天機
TA貢獻1786條經驗 獲得超13個贊
沒有正確答案，這是個人意見和感受的問題。
但是，我認為有些事情是普遍的：
如果您采用測試驅動開發，除非您首先編寫了一個失敗的單元測試，否則您永遠不會編寫任何非測試代碼，這將指導您編寫的測試數量。有了一些 TDD 經驗，您就會對此有所了解，因此即使您需要為未經過 TDD 的舊代碼編寫單元測試，您也可以像經過 TDD 一樣編寫測試。
如果一個類的單元測試太多，則表明該類做了太多事情。然而，“太多”很難量化。但是當感覺太多時，嘗試將班級分成更多的班級，每個班級的職責更少。
模擬是單元測試的基礎——如果不模擬協作者，您測試的不僅僅是“單元”。因此，學習使用模擬框架。
檢查空值并測試這些檢查可能會增加很多代碼。如果您采用一種從不生成 null 的樣式，那么您的代碼就永遠不需要處理 null，也不需要測試在那種情況下會發生什么。
這也有例外，例如，如果您提供庫代碼，并希望向調用者提供友好的無效參數錯誤
對于某些方法，屬性測試可能是一種通過大量測試來命中代碼的可行方法。jUnit
@Theory就是其中的一種實現。它允許您測試斷言，例如 'plus(x,y) 為任何正 x 和正 y 返回正數'
慕姐8265434
TA貢獻1813條經驗 獲得超2個贊
您開發的測試用例集是黑盒測試設計方法的結果，實際上它們看起來就像您應用了分類樹方法一樣。雖然在進行單元測試時暫時采用黑盒視角是完全可以的，但將自己局限于黑盒測試可能會產生一些不良影響：首先，正如您所觀察到的，您最終可能會得到所有每個輸入的可能場景，其次，您可能仍然找不到特定于所選實現的錯誤。
通過（也）采用玻璃盒（又名白盒）視角，您可以避免創建無用的測試：知道您的代碼作為第一步處理重復次數為負的特殊情況意味著您不必將此場景與所有其他場景相乘。當然，這意味著您正在利用您對實現細節的了解：如果您稍后更改您的代碼，以便在多個地方進行針對負重復的檢查，那么您最好也調整您的測試套件。
由于似乎對測試實現細節有廣泛的關注：單元測試是關于測試實現的。不同的實現有不同的潛在錯誤。如果您不使用單元測試來查找這些錯誤，那么任何其他測試級別（集成、子系統、系統）肯定不太適合系統地查找它們——并且在更大的項目中您不希望實現級別的錯誤逃逸到后期的開發階段甚至到現場。附帶說明一下，覆蓋率分析意味著您采用玻璃盒視角，而 TDD 也是如此。
然而，測試套件或單個測試不應不必要地依賴于實現細節是正確的——但這與說你根本不應該依賴實現細節是不同的說法。因此，一種看似合理的方法是，進行一組從黑盒角度來看有意義的測試，以及旨在捕獲那些特定于實現的錯誤的測試。后者需要在您更改代碼時進行調整，但可以通過各種方式減少工作量，例如使用測試輔助方法等。
在您的情況下，從玻璃盒的角度來看，可能會將具有負重復的測試數量減少到一個，還有 null char 情況，也可能是 NullStrB 情況（假設您通過用空字符串替換 null 來盡早處理），等等。
回首憶惘然
TA貢獻1847條經驗 獲得超11個贊
一般的經驗法則通常是代碼中的每個“分支”都應該進行測試，這意味著您應該涵蓋所有可能的邊緣情況。
例如，如果您有以下代碼：
if (x != null) {
if (x.length > 100) {
// do something
} else {
// do something else
}
} else {
// do something completely else
}
您應該有三個測試用例——一個為空，一個為小于 100 的值，一個為更長的值。這是如果你很嚴格并且想要 100% 覆蓋。
無論是不同的測試還是參數化都不那么重要，這更多的是風格問題，你可以選擇任何一種方式。我認為更重要的是涵蓋所有情況。
森林海
TA貢獻2011條經驗 獲得超2個贊
首先，使用代碼覆蓋工具。這將向您顯示測試執行了哪些代碼行。IDE 具有用于代碼覆蓋工具的插件，因此您可以運行測試并查看執行了哪些行。嘗試覆蓋每一行，這在某些情況下可能很難，但對于這種實用程序來說，它是非常可行的。
使用代碼覆蓋工具可以使未發現的邊緣情況脫穎而出。對于難以實現的測試，代碼覆蓋率會向您顯示您的測試執行了哪些行，因此如果您的測試中出現錯誤，您可以看到它進行了多遠。
接下來，了解沒有測試涵蓋所有內容?？倳心粶y試的值。因此，選擇感興趣的代表性輸入，避免那些看起來多余的輸入。例如，傳遞一個空的 StringBuilder 真的是您關心的事情嗎？它不會影響代碼的行為。有一些特殊值可能會導致問題，例如 null。如果您正在測試二分查找，您需要覆蓋數組非常大的情況，以查看中點計算是否溢出。尋找重要的案例類型。
如果您預先驗證并剔除麻煩的值，您就不必進行那么多的工作測試。一項針對 null StringBuilder 的測試是為了驗證您拋出了 IllegalArgumentException，一項針對負重復值的測試是為了驗證您為此拋出了一些東西。
最后，測試是針對開發人員的。做對你有用的事。
添加回答
舉報
0/150
提交
取消