编写长测试方法名称来描述测试与在代码文档中使用

Question

对于编写单元测试，我知道编写看起来像

的测试方法非常流行

public void Can_User_Authenticate_With_Bad_Password()
{
...
}

虽然这样可以很容易地看到测试的测试内容，但我认为它看起来很丑陋并且在自动生成的文档中不能很好地显示（例如sandcastle或javadoc）。

我有兴趣看看人们对使用命名模式的看法，该模式是正在测试的方法，然后是下划线测试，然后是测试编号。然后使用XML代码文档（.net）或javadoc注释来描述正在测试的内容。

/// <summary>
/// Tests for user authentication with a bad password.
/// </summary>
public void AuthenticateUser_Test1()
{
...
}

通过这样做，我可以通过他们正在测试的方法轻松地将我的测试组合在一起，我可以看到我可以对给定的方法进行测试，并且我仍然可以完整地描述正在测试的内容。

我们有一些与数据源（xml文件）运行的回归测试，并且这些文件可能由无法访问源代码（QA猴子）的人更新，他们需要能够读取正在测试的内容以及更新数据源的地方。

Answer 1

我更喜欢“长名”版本 - 虽然只是为了描述发生什么。如果测试需要描述为什么它会发生，我会把它放在评论中（如果合适的话带有错误号）。

使用长名称，当您收到邮件（或其他任何）告诉您哪些测试失败时，更清楚的是出了什么问题。

我会根据 应该做什么来写它：

LogInSucceedsWithValidCredentials

LogInFailsWithIncorrectPassword

LogInFailsForUnknownUser

我不认为它在自动生成的文档中看起来很糟糕 - 为什么你首先在 tests 上运行JavaDoc？我不能说我曾经这样做过，或者想要生成的文档。鉴于测试方法通常没有参数并且不返回任何内容，如果方法名称可以合理地描述它们所需的所有信息。测试运行器应该能够列出它运行的测试，或者IDE可以向您显示可用的测试。我发现比通过HTML导航更方便 - 浏览器没有“查找类型”，只允许我键入名称中每个单词的第一个字母，例如......

Answer 2

文档是否出现在您的测试运行器中？如果不是，那么使用长的描述性名称是一个很好的理由。

就个人而言，我更喜欢长名称，很少看到需要在测试中添加注释。

Answer 3

我已经完成了关于相关主题的论文，所以这是我的两分钱：每当你依靠文档传达一些不在你的方法签名中的东西时，你就冒很大的风险，没有人会阅读文档

当开发人员正在寻找特定的东西时（例如，在类中扫描一长串方法以查看他们正在寻找的是否已存在），他们中的大多数都不会费心阅读文档。他们希望处理一种他们可以轻松查看和比较的信息（例如，名称），而不必开始重定向到其他材料（例如，悬停足够长时间以查看JavaDocs）。

我强烈建议您传阅签名中的所有相关内容。

Answer 4

我个人更喜欢使用长方法名称。请注意，您还可以在表达式中包含方法名称，如：

Can_AuthenticateUser_With_Bad_Password()

Answer 5

我建议更小，更专注（测试）的课程。

为什么要进行javadoc测试？

Answer 6

如何改变

Can_User_Authenticate_With_Bad_Password

到

AuthenticateDenieTest
AuthenticateAcceptTest

并且名称类似于User

Answer 7

作为一个群组，我们如何看待像这样的混合命名模式

/// <summary>
/// Tests for user authentication with a bad password.
/// </summary>
public void AuthenticateUser_Test1_With_Bad_Password()
{
...
}

我们将两者都做到最好。