2009-05-26 41 views
1

我使用的是NUnit 2.5,我想測試一個接收幾個參數的方法。
嘗試使用一種測試方法對幾種不同的測試案例進行測試是合理的嗎?或者從長遠來看難以維護(或只是指出確切的故障)?在一種方法中測試幾個不同結果的單元

我總的想法是嘗試像

[TestCase("valid", Result="validasd", 
    Description = "Valid string test, expecting valid answer")] 
[TestCase(null, ExpectedException = typeof(ArgumentNullException), 
    Description = "Calling with null, expecting exception")] 
[TestCase("", ExpectedException = typeof(ArgumentException), 
    Description = "Calling with an empty string, expecting exception")] 
public string TestSubString(string value) 
{ 
    return MethodUnderTest(value); 
} 

是不是也推薦使用 - 沒有明確的斷言,只是返回值檢查?或者我應該堅持正常的方式還是堅持方法內的價值?

回答

3

我發現TestCase的屬性測試,其主要接受一些簡單的值,與他們計算,然後返回結果的方法時是有用的。在這些情況下,編寫這樣的測試花費的開銷和重複要少得多。

當該方法需要複雜的對象參數,因爲測試用例屬性只能接受原始類型作爲輸入參數傳遞給該方法該方法不工作。

您可能還需要考慮寫一個比較典型的單元測試,如果:

  1. 在你的團隊的其他開發人員不熟悉這種技術
  2. 可能改變或適應多個參數的方法的簽名
  3. 如果有超過測試用例或值的組合極少數測試
  4. 你需要測試按照特定的順序來執行
  5. 要る在Visual Studio中使用ReSharper進行測試(它目前不能識別TestCase屬性)
+0

我還使用指向IEnumerable 字段的TestCaseSource屬性編寫了一些帶有更復雜參數和返回值的測試。我認爲這有點太過分 - 這樣數據,更重要的是斷言邏輯,遠離測試本身,這將明確地讓它難以理解。 感謝您的輸入。 (也對其他人) – 2009-05-26 14:15:28

0

我會避免這種情況。這將是非常難以維持。我會爲每種情況提供一種測試方法。

+0

您爲什麼認爲這是一個難以維護的方法?它將調用該方法的因素列出,並澄清這些是測試的變體。我看到的唯一缺點(支持您的觀點)是,當方法簽名更改時,大多數重構工具都無法修改這些屬性。 – LBushkin 2009-05-26 13:54:08

0

我認爲陪審團仍然是對這種參數的測試 - 硬核TDDers可能會說,它違反了原則通過了「每一個測試斷言」,他們可能是正確的。單元測試中最重要的事情是,當測試失敗時,您可以快速確定失敗的原因,哪些輸入導致失敗,並通過重新運行相同的測試來重現它。雖然前兩種可能不是這種測試結構的問題,但第三種可能會(雖然有足夠聰明的工具可以解決這個問題)。我個人至少應該說你應該把測試用例分成結果集,也就是說,如果兩組參數具有相同的預期結果(比如ArgumentException),可以把它們放在同一個測試中方法。但在你的例子中,所有三個參數都有不同的預期結果,所以你應該把它們放在不同的測試方法上。

0

對我來說,最好的方法往往是讓你寫更少代碼的方法。該屬性的方法是在我看來更好,因爲:

  • 測試運行意志集團同樹節點
  • 視覺下的那些方法,很明顯,這3個測試用例適用於相同的代碼,只是方法的參數正在改變,如果測試失敗,錯誤信息仍然會告訴你哪些參數使其失敗
  • 減少代碼!

缺點是參數和返回值是硬編碼的,所以你不能測試動態或隨機生成的參數,這在某些情況下是有用的。

0

寫這樣的東西不是更好嗎?

[Test] 
public string TestSubString() 
{ 
    Assert.AreEqual("validasd", MethodUnderTest("valid")); 
    AssertEx.Throws<ArgumentNullException>(() => { MethodUnderTest(null); }); 
    AssertEx.Throws<ArgumentException>(() => { MethodUnderTest(""); }); 
} 
相關問題