命名单元和集成测试方法的最佳做法是什么？

Question

我最近继承了不同人在不同时间编写的应用程序，并寻找关于如何标准化的指导。

Answer 1

假设NUnit的：

[Test] 
public void ObjectUnderTest_StateChanged_Consequence() 
{ 
    Assert.That(tra_la_la); 
} 

[Test] 
public void ObjectUnderTest_Behaviour_Consequence() 
{ 
    Assert.That(tra_la_la); 
} 

例如：

[Test] 
public void WifeIsTired_TakeWifeToDinner_WifeIsGrateful() 
{ 
    Assert.That(tra_la_la); 
} 

[Test] 
public void WifeIsTired_MentionNewGirlfriend_WifeGetsHalf() 
{ 
    Assert.That(tra_la_la); 
} 

Answer 2

我遇到了两个很好的建议。链接在这里：http://slott-softwarearchitect.blogspot.com/2009/10/unit-test-naming.html

http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx

http://openmrs.org/wiki/Unit_Testing_with_@should

Answer 3

在这种情况下我可能会发现，使用最多和重构代码的其余部分使用的命名约定。如果最常用的是真的很可怕，我仍然会看现有的代码，并试图找到一个可以与之共存的代码。一致性比任意惯例更重要。

Answer 4

我使用FunctionTestCondition构造。如果我有两个方法，Get和Set我也许会创建以下测试方法：

• GetTest是一个积极的测试（一切正常）。
• GetTestInvalidIndex测试传递给方法的无效索引。
• GetTestNotInitialized用于测试数据在使用前未被检测的时间。
• SetTest
• SetTestInvalidIndex
• SetTestTooLargeValue
• SetTestTooLongString

Answer 5

它的启发看看BDD（行为驱动开发）和this blog post尤其如此。

BDD本质上集中在组件上，他们应该做什么。因此，它会直接影响您如何命名/构建测试，以及它们用于设置条件和验证的代码。 BDD不仅允许开发人员读/写测试，而且团队中的非技术成员（业务分析师等）可以通过指定测试和验证测试来做出贡献。

Answer 6

我只写了它的用途。这不像是你必须在其他地方输入名字，所以有testWibbleDoesNotThrowAnExceptionIfPassedAFrobulator不是一个问题。任何测试都是以“测试”开始的，显然。

Answer 7

通过设置对您的测试进行分组，围绕此设置制作一个测试类，名称使用后缀Test或IntegrationTest。使用像JUnit或TestNG这样的测试框架，您可以根据需要为测试方法命名。我会将该方法命名为它测试的内容，一个骆驼案例，而不是测试前缀。该框架使用一个@Test注释将方法标记为测试。

Answer 8

没有标准正因为如此，不同的人/地方都会有不同的方案。重要的是你坚持为标准。

个人，我的下面的风扇 - 在C＃示例代码，但非常接近的Java，适用同样的规则：

[Test] 
public void person_should_say_hello() 
{ 
    // Arrange 
    var person = new Person(); 
    // Act 
    string result = person.SayHello(); 
    // Assert 
    Assert(..., "The person did not say hello correctly!"); 
} 

明确

该测试的名称应该有的名称被测试的类别。在这个例子中，被测试的类是Person。测试名称还应具有正在测试的方法的名称。这样，如果测试失败了，你至少知道在哪里寻找解决方法。我还建议遵循AAA - Arrange, Act, Assert规则，这将确保您的测试易于阅读和遵循。

场所的失败消息

当涉及到断言结果/状态，其有用的是包括一个可选的消息。这使得测试失败时更容易，特别是作为构建过程的一部分运行或通过外部工具运行时。

下划线

最后的（虽然是可选的）立场，我所遵循的是使用测试名称中使用下划线。虽然我并不喜欢生产代码中的下划线，但它们在测试名称中的使用非常有用，因为测试名称通常要长得多。快速浏览一个使用下划线的测试名称，证明其可读性更高，尽管这是主观的，并且是单元测试实践中争论的焦点。

集成测试

同样的标准适用于集成测试，唯一的区别是这样的测试应是从单元测试分开的位置。在上面的示例代码中，测试类将被称为PersonTests，并位于名为PersonTests.cs的文件中。集成测试将以类似的方式命名 - PersonIntegrationTests，位于PersonIntegrationTests.cs。同一个项目可以用于这些测试，但确保它们位于不同的目录中。