单元测试名称重要吗?

任何方法的名称都应该清楚地说明它的作用。

依我看,你的第一个建议有点长,第二个建议的信息量不够。此外,在名称中加上“100”可能是个坏主意,因为这很可能会改变。那么:

public void validateUserNameLength()

如果测试更改,则应相应地更新名称。

post about it .

此外,将好的测试名称与 one assertion per test 当测试失败时,您的套件将为您提供出色的报告。

如果您的测试套件将在将来被新的开发人员引用,那么您的测试套件将更加有用。

至于你原来的问题,一定要回答。多输入几个字符是一个很小的代价

• 可读性。为你和其他人。它将消除“我在想什么?”以及“这家伙在测试中有什么意思?”
• 当你在修复别人写的东西时,快速放大

对

 [Test]
 public void UsernameValidator_LessThanLengthLimit_ShouldValidate() {}

将测试主题放在第一位,测试语句放在第二位,预期结果放在最后。
这样,您就可以清楚地知道它在做什么,并且可以轻松地按名称排序:)

在里面 Clean Code ,第124页, Robert C. Martin 写道:

这个故事的寓意很简单: 它不是二等公民。它需要思考、设计和关怀。它必须像生产代码一样保持清洁。

我认为,如果一个人不能为一个测试方法找到一个好的简明的名字,这表明这个测试的设计是错误的。另外,好的方法名可以帮助您在更短的时间内找出发生了什么。

我不会把测试需要满足的条件放在名字里,因为条件可能会随着时间而改变。在你的例子中,我建议命名为

UserNameLengthValidate()

或

UserNameLengthTest()

或者类似的解释测试的作用,但不假定测试/验证参数。

是的,被测试代码的名称(方法、属性等)可能会改变,但我认为如果期望值改变,您现有的测试应该会失败。这就是构建良好的测试的真正价值,而不是仔细阅读测试名称列表。这就是说,命名良好的测试方法是吸引新开发人员加入的好工具,帮助他们找到“可执行文档”,他们可以利用这些文档摆脱现有代码的束缚——因此,我将保持测试方法的名称最新,就像我将保持测试方法的断言最新一样。

我使用以下模式命名我的测试。每个测试夹具都试图集中在一个类上,通常称为{ClassUnderTest}test。我将每个测试方法命名为{MemberUnderTest}{Assertion}。

[TestFixture]
public class IndexableFileTest
{
   [Test]
   public void Connect_InitializesReadOnlyProperties()
   {
     // ...
   }

   [Test,ExpectedException(typeof(NotInitializedException))]
   public void IsIndexable_ErrorWhenNotConnected()
   {
     // ...
   }

   [Test]
   public void IsIndexable_True()
   {
     // ...
   }

   [Test]
   public void IsIndexable_False()
   {
     // ...
   }
}

有一个非常描述性的名称有助于立即发现哪些工作不正常,因此您实际上不需要查看单元测试代码。 此外,所有单元测试的列表描述了单元的预期行为,并且可以(或多或少)用作被测单元行为的文档。

例如:

[Test]
void TestThatExceptionIsRaisedWhenStringLengthLargerThen100()

[Test]
void TestThatStringLengthOf99IsAccepted()

名称必须合理。我不想让构建人员发邮件说测试389fb2b5-28ad3失败,但只要知道这是用户名测试而不是其他测试,就可以帮助确保正确的人进行诊断。

[RowTest]
[Row("GoodName")]
[Row("GoodName2")]
public void Should_validate_username()
{
}

[RowTest]
[Row("BadUserName")]
[Row("Bad%!Name")]
public void Should_invalidate_username()
{
}

这对于更复杂的验证类型可能更有意义。

是的,他们是。我个人建议你看看 SSW's rules to better unit tests