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

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

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

Answer 2

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

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

Answer 3

我已经完成了有关相关主题的论文，因此这是我的两点意见：任何时候您依赖文档来传达方法签名中未包含的内容时，您都会冒着没有人会阅读文档的巨大风险。

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

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

Answer 4

改变又怎样

Can_User_Authenticate_With_Bad_Password

到

AuthenticateDenieTest
AuthenticateAcceptTest

和名字适合类似的东西User