2009-09-14 128 views
15

由於單元測試方法的命名使其目的更有意義,是否需要爲單元測試方法添加彙總?單元測試方法需要彙總

例子:

/// <summary> 
/// Check the FormatException should be thrown when a give country data line contains a invalid number. 
/// </summary> 
[TestMethod] 
public void FormatException_Should_Thrown_When_Parse_CountryLine_Containing_InvalidNumber() 
{ 
    ... 
} 
+0

其他人看到Skeet奇怪的回答,然後幾乎立即刪除它? – Will 2009-09-14 14:17:55

+0

@會 - 我也注意到了。 – 2009-09-14 14:19:52

+0

@請問這有什麼關係嗎? – RichardOD 2009-09-14 14:21:34

回答

9

我認爲長的描述性名稱比XML評論更重要。由於單元測試不會成爲API的一部分,因此您不需要XML註釋。

例如:

[TestMethod] 
public void FormatException_Should_Thrown_When_Parse_CountryLine_Containing_InvalidNumber() 
{ 
    ... 
} 

是比較有用的比:

///<summary> 
/// Exception Should Thrown When Parse CountryLine Containing InvalidNumber 
///</summary> 
[TestMethod] 
public void Test42() 
{ 
    ... 
} 

XML註釋應被用於記錄API和框架。

+0

+1。另外我從來沒有見過單元測試的文檔。如果代碼編寫得很好,它應該是自我描述的。這是典型的,如果你使用組合方法 - http://c2.com/ppr/wiki/WikiPagesAboutRefactoring/ComposedMethod.html – RichardOD 2009-09-14 14:26:47

0

沒有必要的,但如果你覺得XML註釋添加超越單元測試本身(這看起來很全面)的名稱值,那麼你會做其他開發者一項服務。

如果摘要基本上是單元測試方法名稱的直接副本,那麼我認爲這是矯枉過正。

1

就我個人而言,我試圖讓測試變得簡單易懂,以至於文檔將是多餘的。我在測試方法中使用內聯註釋來解釋爲什麼我正在做某件事情,而不是我在做什麼

-1

如果你認爲這是你最好的時間使用,那麼做,否則不要。我不會。

0

對於上面的例子,我會說這是沒有必要的,除非你使用的工具從源文件中提取文檔(如javadoc或其他)。

一個常見的經驗法則是,代碼說你在做什麼和評論說明了爲什麼,但由於名稱非常冗長(我認爲是好的,因爲沒有人必須輸入它)不要以爲評論有什麼貢獻。

0

當摘要可以提供更多可以/應該用方法名稱編碼的信息時,需要添加摘要。請注意,在提及任何文檔時,當我說「必要」時,我的意思是「必須向繼承項目的新編碼人員或5年後自己向您傳送100%所需的上下文/詳細信息/細微差別」。

37

我實際上更喜歡在摘要標籤上使用DescriptionAttribute。原因是Description屬性的值將顯示在結果文件中。它使故障更容易理解,當你只是在尋找一個日誌文件

[TestMethod,Description("Ensure feature X doesn't regress Y")] 
public void TestFeatureX42() { 
    .. 
} 
+0

這顯示在測試列表中可能有幫助。 – Will 2009-09-14 14:30:49

+0

+1。是的,這聽起來像個好主意。 – RichardOD 2009-09-14 14:35:31

+0

+1我也是。對於所有項目,包括測試項目,都應該保留方法的命名約定 - 在方法名稱中放置摘要或描述而不是爲了保存這些數據而設計的地方是什麼理由? – Spook 2012-10-17 06:04:20

0

XML註釋是完全不必要的,如果你有一個描述性的方法名。這是單元測試方法的必要條件。

你已經在正確的軌道上有一個描述性的測試方法名稱。 (許多敏捷和TDD從業者認爲測試方法應該包括「應該」,例如link text這篇博文中所示。

就個人而言,我喜歡的方法名是這樣的:

MyClass_OnInvalidInput_ShouldThrowFormatException() 

但是,這僅僅是我個人的偏好。