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

对于编写单元测试,我知道编写看起来像的测试方法非常流行

public void Can_User_Authenticate_With_Bad_Password()
{
...
}

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

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

/// 

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

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

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

我更喜欢"长名称"版本-虽然只来形容什么情况.如果测试需要描述其发生的原因,我会将其放在注释中(如果合适,还会带有错误编号).

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

我会根据它应该做的事情来写它:

LogInSucceedsWithValidCredentials

LogInFailsWithIncorrectPassword

LogInFailsForUnknownUser

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

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

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