对于编写单元测试，我知道很流行编写看起来像这样的测试方法
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 猴子)更新，他们需要能够阅读正在测试的内容以及更新数据源的位置。
最佳答案
我更喜欢“长名称”版本——尽管只是为了描述发生了什么。如果测试需要描述它发生的原因，我会把它放在评论中(如果合适的话，加上错误编号)。
有了长名称，当您收到一封告诉您哪些测试失败的邮件(或其他任何内容)时，会更清楚出了什么问题。
不过，我会根据它应该做什么来写它:
LogInSucceedsWithValidCredentials
LogInFailsWithIncorrectPassword
LogInFailsForUnknownUser
我不认同自动生成的文档看起来很糟糕的论点 - 为什么首先要在测试上运行 JavaDoc？我不能说我曾经这样做过，或者想要生成文档。鉴于测试方法通常没有参数并且不返回任何内容，如果方法名称可以合理地描述它们，那么这就是您需要的所有信息。测试运行器应该能够列出它运行的测试，或者 IDE 可以向您显示可用的测试。我发现这比通过 HTML 导航更方便 - 浏览器没有“查找类型”功能，让我可以只输入名称中每个单词的首字母，例如...
关于java - 编写长测试方法名称来描述测试与在代码文档中使用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/706354/