2009-09-14 212 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() 

但是,这仅仅是我个人的偏好。