单元测试方法中是否需要摘要答案

【问题标题】：Is summary necessary in unit test method单元测试方法中是否需要摘要
【发布时间】：2010-11-28 03:40:59
【问题描述】：

既然单元测试方法的命名使其目的更有意义，那么单元测试方法是否需要添加摘要？

例子：

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

【问题讨论】：

其他人看到 Skeet 的回答很奇怪，然后几乎立即将其删除？
@Will - 是的，我也注意到了。
我们是开发者。注意到不正常的奇怪事物是我们大脑的工作方式:)
发布答案并没有什么不正常的地方，意识到您误读了问题并将其删除。
这就是我们所说的飞碟。他走得很完美。而且，坦率地说，你应该因为认为他是人类而被禁止。这家伙是 T10k，当他追踪到你时，他会撕掉你的脊椎。

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

【解决方案1】：

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

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

【讨论】：

+1 我也是。应为所有项目（包括测试项目）保留方法的命名约定 - 将摘要或描述放在方法名称中而不是为保留此类数据而设计的位置有什么合理的理由？
您能否评论一下现在测试资源管理器如何与Description 属性集成？我知道这篇文章很旧，但我从来不知道有一个专门针对测试的描述属性，并立即添加了一个以查看它的外观。令我惊讶的是，我在任何地方都看不到它。是否删除了该功能（在这种情况下，该属性不会被弃用吗？）还是我遗漏了什么？
@julealgon 至少 VS 2015 似乎确实如此。 DescriptionAttribute 不会显示在 IDE 中的任何位置，即使在测试运行失败时也是如此。我需要检查 VSTest.Console 的控制台记录器是否足够好，至少可以将其输出到控制台以进行失败的测试。
@TanveerBadar 这对我来说真的很沮丧，你会认为他们会在解决方案资源管理器中添加类似的东西。这个问题我不是the only one...
与 Visual Studio 2017 相同的问题。描述属性无用。

【解决方案2】：

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

【讨论】：

+1 来自我。此外，我从未见过来自单元测试的文档。如果代码编写得很好，它应该是自我描述的。如果您使用组合方法，这是典型的 - c2.com/ppr/wiki/WikiPagesAboutRefactoring/ComposedMethod.html

【解决方案3】：

就我个人而言，我尽量让测试变得足够简单，以便阅读文档将是多余的。我在测试方法中使用内联 cmets 来解释为什么我以特定的方式做某事，而不是什么我在做什么。

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

没有必要，但如果您觉得 XML cmets 的附加值超出了单元测试本身的名称（看起来很全面），那么您将为其他开发人员提供服务。

如果摘要本质上是单元测试方法名称的直接复制，那么我认为这是矫枉过正。

【讨论】：

【解决方案6】：

对于上面的示例，我想说这不是必需的，除非您使用从源代码中提取文档的工具（如 javadoc 或其他东西）。

一个常见的经验法则是代码说明了您在做什么，而注释说明了原因，但是由于名称非常冗长（我认为这没问题，因为没有人需要输入它）我不知道'认为评论没有任何贡献。

【讨论】：

【解决方案7】：

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

您已经在正确的轨道上拥有一个描述性的测试方法名称。（许多敏捷和 TDD 实践者认为测试方法应该包含“应该”，例如 link text 这篇博文中所示。

就个人而言，我喜欢这样的方法名称：

MyClass_OnInvalidInput_ShouldThrowFormatException()

但这只是我个人的喜好。

【讨论】：

【解决方案8】：

如果您认为这是对您时间的最佳利用，那就去做吧，否则就不要这样做。我不会。

【讨论】：