應該爲代碼分支應用什麼樣的單元測試組合？

如果我也不太清楚其下面的測試將是必要的或冗餘。考慮單元測試下面的代碼：應該爲代碼分支應用什麼樣的單元測試組合？

public class Locker { 

    public enum Type { FOO, BAR, FOOBAR }; 

    private Locker() {} 

    public boolean shouldlock (int x) { 
     return x > 10; 
    } 

    public boolean lock (Type type, int x) { 
     switch (type) { 
      case FOO : return shouldlock(x); 
      case BAR : return shouldlock(x * 2); 
     } 
     return false; 
    } 
}

測試案例1：兩個真假的情況下測試shouldlock。 - 毫無疑問，迄今爲止。

Question 1：

測試用例2：lock輸入類型Foo真假情況下還進行測試，即，它們兩者。？根據它的調用shouldlock，我們已經測試了兩種情況。因此它可能是多餘的。但不太確定。

Question 2：

測試案例3：假設答案Question1是真的，我們是否還需要測試Bar真假呢？

Question 3：

測試案例4：假設答案都Question1 and Question2是真實的。現在假設shouldlock更改爲私有（只是假設它）。測試的唯一區別是我應該省略Test case 1？

Question 4：

測試案例5：是否需要檢查，唯一的冷落枚舉FOOBAR返回false？

Question 5：

假設回答問題4是真實的，那麼如果明天怎樣枚舉包含100多個項目？如何擴展這樣的測試？

來源

2014-01-06 JavaDeveloper

附註：'return x> 10？ true：false;'可以簡化爲'return x> 10;' – Keppil

測試案例1 - 是的，在邊界條件（10,11）上測試真假案例。

測試用例2 - 模擬shouldlock並驗證它是用x（可能使用恆定值進行測試）調用的。使用諸如Mockito之類的東西，並且只有在致電lock時才使用真正的方法。

測試用例3 - 與測試用例2相同，但驗證shouldlock被稱爲x * 2。

測試案例4 - 你必須測試每種類型的邊界情況：FOO 10和11，BAR 5和6

測試用例5 - 是的，只有一個測試FOOBAR是必須的。

您必須爲新值編寫測試。如果有更多的枚舉值，但它們都轉到默認情況下，則不需要更多的單元測試。如果有其他邏輯，應該寫入單元測試（最好在生產代碼之前）以測試該邏輯。

來源

2014-01-06 21:32:21

首先，這取決於它們是你的代碼具有場景照顧。從這個角度來看，您可以考慮以測試驅動開發（TDD）的方式來處理您的工作，其中您首先編寫應該涵蓋所需功能的測試，並編寫使測試通過的代碼。

採用這種方法，對於您的問題沒有通用有效的答案。這隻取決於你需要什麼以及你需要多嚴格。

其次，你可以注意以下幾點想法接近你的單元測試：做單元測試代碼覆蓋率儘可能高。我想在這裏多是關於線覆蓋和條件覆蓋。這意味着在單元測試期間執行的代碼應該儘可能多地包含行，並且它應該分別覆蓋儘可能多的條件分支。此外，使用這種方法，您可能希望儘可能減少冗餘，即保持一條線的執行次數儘可能低，但高於0（理想情況下爲1）。在這種情況下，問題的答案是：

只有一個的情況下，無論是true或false。
測試BAR情況下，其中一個案件，但測試（要覆蓋case BAR線。
只要你涵蓋true和false箱子，是的。
是的，你想還覆蓋return false線。
代碼覆蓋是很重要的，但是當它不還清不誇大。:)

來源

2014-01-06 21:26:18

我知道這是一個爲了這個問題而做的人爲的例子，所以我會回答一般情況。

您想用盡可能多的輸入進行測試，以確保代碼正常工作。當然，你可能會錯過一些東西，但是當你需要稍後重新創建錯誤時，測試將會在那裏。就像一個非常低的負數，非常高的正數，0，比較有代表性的數字你所期望的 -

在shouldlock的情況下，我會用一組緩解我心中的整數代碼可以運行測試輸入。

至於lock，您的問題表明您正在考慮執行方面，我認爲這是一個錯誤。您需要根據方法的客戶來思考。具體而言，不要說「我們是否還需要測試BAR？」相反，您只需要考慮客戶端可以調用您的方法的合理數量並進行相應的測試。這意味着您的所有enum值。在規模方面，我認爲這個問題沒有實際意義，因爲使用100項enum進行測試的難度（儘可能不那麼可能）表明您應該更改實現，因此您的方法可能會發生變化。然後你的測試就會反映出來。

至於改變方法爲private，那麼你不必再測試它了。只有你的公共API需要被測試。儘管如此，您可能還想將斷言添加到這些方法中。

底線是不要在100％的測試覆蓋率痛苦。收益遞減，並且當發現錯誤時，您將有可用的測試來重現並修復它。

來源

2014-01-06 21:32:39 Vidya

應該爲代碼分支應用什麼樣的單元測試組合？

回答

相關問題