在单元测试方法中需要总结

时间:2009-09-14 14:13:28

标签: c# visual-studio unit-testing mstest

由于单元测试方法的命名使其目的更有意义,是否有必要将摘要添加到单元测试方法中?

示例:

/// <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()
{
  ...
}

8 个答案:

答案 0 :(得分:41)

我实际上更喜欢在摘要标记上使用DescriptionAttribute。原因是Description属性的值将显示在结果文件中。当您只是查看日志文件时,它会使故障更容易理解

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

答案 1 :(得分:10)

我认为长描述性名称比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和框架。

答案 2 :(得分:1)

就个人而言,我试图让测试变得容易,以至于文档是多余的。我在测试方法中使用内联注释来解释为什么我正在以某种特定的方式做某事,而不是我在做什么

答案 3 :(得分:0)

没有必要,但如果您认为XML注释增加了超出单元测试本身名称的值(看起来很全面),那么您将为其他开发人员提供服务。

如果摘要基本上是单元测试方法名称的直接副本,那么我认为这是过度的。

答案 4 :(得分:0)

对于上面的示例,我会说没有必要,除非您使用从源代码中提取文档的工具(如javadoc或其他东西)。

一个常见的经验法则是代码说明你正在做什么,评论说明为什么,但因为这个名字非常冗长(我认为没问题,因为没有人必须输入它)我不喜欢不要认为评论有所贡献。

答案 5 :(得分:0)

当摘要可以提供可以/应该在方法名称中编码的更多信息时,有必要添加摘要。请注意,当我在提及任何文档时说“必要”时,我的意思是“必须向继承该项目的新编码人员传达100%所需的背景/细节/细微差别,或者在5年后向您自己传达”。

答案 6 :(得分:0)

如果您有描述性方法名称,则完全不需要XML注释。对于单元测试方法来说,这是必须的。

您已经在正确的轨道上拥有描述性测试方法名称。 (许多敏捷和TDD从业者认为测试方法应该包括“应该”,例如link text此博客文章中所示。

就个人而言,我喜欢这样的方法名称:

MyClass_OnInvalidInput_ShouldThrowFormatException()

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

答案 7 :(得分:-1)

如果您认为这是最好的利用时间,那就去做吧,否则不行。我不会。