建議用於JUnit進行測試

在寫方法A的測試方法（其具有許多內部條件），我應着重於測試每個時間單個條件？我發現很難構建方法A的測試方法，它將覆蓋方法A中的所有代碼路徑。

任何人都可以請我建議我如何去編寫測試方法。

2010-11-02 name_masked

我的首選項是每個JUnit測試方法都有一個失敗點。這意味着我將測試每個目標類方法的許多JUnit測試方法。在你的例子中，我可能有testA1（），testA2（），testA3（）全部測試同樣的方法（A）。每種方法都會測試方法A的不同成功或失敗情況。

如果通過方法A有8個路徑，那麼您至少需要8個測試方法調用它，也可能有一些方法用於錯誤處理條件。

來源

2010-11-02 16:33:20 DwB

謝謝。另外，如果我正在測試的方法拋出IOException，那麼我的測試方法應該拋出相同的異常嗎？即'公共無效testA1（）拋出IOException'？ – 2010-11-02 17:00:32

在JUnit測試方法中捕獲異常。您應該包含強制拋出異常的JUnit測試方法（如果可能）。根據預期的調用結果將您的JUnit測試失敗或傳遞到您的方法中。如果JUnit測試方法期望拋出異常xxx並且正在測試的方法拋出異常xxx，則JUnit測試方法會成功。 – DwB 2010-11-02 19:09:07

如果你正在測試的方法聲明它拋出IOException異常，但是特定的測試不應該引發這個異常被拋出，那麼是的，你的測試方法應該聲明拋出IOException（我通常只是說「throws Exception」）。你不想在測試中捕獲異常，除非你試圖測試一個方法，如果給定參數和對象的狀態，應該拋出一個異常。 – NamshubWriter 2010-11-03 07:08:05

不要覺得需要每個方法進行一次測試。保持單元測試的細緻，描述性和易於理解。如果這意味着多個相似的測試都會調用相同的目標方法，那麼就這樣做。

對於這個問題，儘量避免爲每種方法系統編寫單元測試的習慣。單元測試應該經過深思熟慮，而不是習慣性的。他們應該描述類的行爲，而不是單個方法。

來源

2010-11-02 16:23:41 skaffman

+1。我經常將那些設計用於引發異常（例如@Test（expected = SomeException.class））的測試與滿足各種斷言的測試分開。複雜的方法可能有十幾個測試用例，而更簡單的方法可以用一個測試用例進行充分的測試。 – Fil 2010-11-02 16:33:54

你應該爲每個執行路徑寫一個測試。例如，如果您有

if (cond1 || cond2) {....}

您應該測試cond1和cond2。如果有意義的話，單獨的測試方法是很好的，也是鼓勵的。它的確定有

testMyMethodCond1(){...}

和

testMyMethodCond2(){...}

和其他任何你需要的。另外，當你說你的方法有'很多內部條件'時，也許你想重構你的代碼，所以這些條件中的一些被其他更小的方法處理，這些方法更容易測試。

來源

2010-11-02 16:25:20 hvgotcodes

首先，如果它有多個責任，你應該考慮將你的方法分解成幾種方法。其次，我建議你爲每種方法編寫多個測試。每個測試應涵蓋通過測試方法的特定路徑。每個測試也應該（當然）根據您的測試數據給出預期的結果。

來源

2010-11-02 16:26:52 Unyttig

測試應該比測試的東西更簡單，最好更簡單。否則，錯誤更可能在您的測試中。所以最好有很多簡單的小測試方法來執行你的方法的一小部分，而不是一個笨重的測試方法。（您可以使用像Cobertura這樣的代碼覆蓋工具來驗證您是否覆蓋了您方法中的所有路徑。）

來源

2010-11-02 16:29:01

建議用於JUnit進行測試

回答

相關問題