单元测试命名最佳实践

命名单元测试类和测试方法的最佳实践是什么？

之前，在SO上讨论了哪些流行的单元测试命名约定？

我不知道这是否是一个很好的方法，但是目前在我的测试项目中，我在每个生产类和一个测试类（例如Product和）之间都有一对一的映射ProductTest。

在测试类中，我有一些方法，这些方法带有要测试的方法的名称，下划线，然后是情况和我希望发生的事情，例如Save_ShouldThrowExceptionWithNullName()。

我喜欢Roy Osherove的命名策略，如下所示：

[UnitOfWork_StateUnderTest_ExpectedBehavior]

它以结构化方式具有方法名称所需的所有信息。

工作单位可以小到单个方法，一个类，也可以大到多个类。它应该表示在此测试用例中要测试且受控制的所有事物。

对于程序集，我使用典型的.Tests结尾，我认为该结尾很普遍，并且对于类（以结尾Tests）也是如此：

[NameOfTheClassUnderTestTests]

以前我使用Fixture作为后缀而不是Tests，但是我认为后者更为常见，然后我更改了命名策略。

我喜欢遵循“应”命名标准进行测试，同时在被测单元（即课程）之后命名测试夹具。

进行说明（使用C＃和NUnit）：

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

为什么要“应该”？

我发现这迫使测试作者使用“应该（处于某种状态）[在[发生]之前/之后/何时] [采取某种行动]”这样的句子来命名测试。

是的，到处都写“应该”确实有点重复，但是正如我说的那样，它迫使作家以正确的方式思考（所以对新手来说可能是有益的）。加上它通常会产生可读的英语测试名称。

更新：

我注意到Jimmy Bogard还是'should'的粉丝，甚至拥有一个名为Should的单元测试库。

更新（4年后...）

对于那些感兴趣的人，多年来我对测试的命名方式已经发展。上面我描述的Should模式的问题之一是，一眼就很难知道正在测试哪种方法。对于OOP，我认为从被测方法开始测试名称更有意义。对于设计良好的类，这应导致可读的测试方法名称。我现在使用类似于的格式<method>_Should<expected>_When<condition>。显然，根据上下文，您可能需要将Should / When动词替换为更合适的内容。例： Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

我喜欢这种命名方式：

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

等等。对于非测试人员来说，这确实是问题所在。

肯特·贝克（Kent Beck）建议：

• 每个“单元”（程序类别）一个测试夹具。测试装置本身就是类。测试夹具名称应为：

  [name of your 'unit']Tests
  

• 测试用例（测试夹具方法）的名称如下：

  test[feature being tested]
  

例如，具有以下类别：

class Person {
    int calculateAge() { ... }

    // other methods and properties
}

测试夹具为：

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

类名。对于测试装置名称，我发现“测试”在许多领域的通用语言中非常普遍。例如，在工程领域：StressTest和化妆品领域：SkinTest。很抱歉不同意Kent，但在我的测试装置中使用了“ Test”（StressTestTest？）中令人困惑。

“单元”在域中也经常使用。例如MeasurementUnit。是称为MeasurementUnitTest“ Measurement”或“ MeasurementUnit”的测试的类吗？

因此，我喜欢对所有测试类使用“ Qa”前缀。例如QaSkinTest和QaMeasurementUnit。它永远不会与域对象混淆，并且使用前缀而不是后缀意味着所有测试夹具都可以在视觉上一起使用（如果您在测试项目中有伪造品或其他支持类，则很有用）

命名空间。我使用C＃工作，并且将测试类与它们正在测试的类放在同一命名空间中。比拥有单独的测试名称空间更方便。当然，测试类在另一个项目中。

测试方法名称。我喜欢将我的方法命名为WhenXXX_ExpectYYY。它使前提条件变得清晰，并有助于自动化文档编制（例如TestDox）。这与Google测试博客上的建议类似，但前提条件和期望值之间存在更大的区别。例如：

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

我使用Given-When-Then概念。看看这篇简短的文章http://cakebaker.42dh.com/2009/05/28/given-when-then/。本文从BDD的角度描述了此概念，但是您也可以在TDD中使用它，而无需进行任何更改。

请参阅：http : //googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsfully.html

对于测试方法名称，我个人觉得使用冗长的自记录名称非常有用（以及Javadoc注释，这些注释进一步说明了测试的功能）。

我认为最重要的事情之一就是您的命名约定保持一致（并与团队中的其他成员达成一致）。很多时候，我看到在同一项目中使用了许多不同的约定。

我最近想出了以下约定来命名测试，它们的类和包含项目，以便最大程度地描述它们：

可以说我正在测试名称空间中Settings项目中的类MyApp.Serialization。

首先，我将使用MyApp.Serialization.Tests名称空间创建一个测试项目。

在这个项目中，当然在命名空间中，我将创建一个名为IfSettings（保存为IfSettings.cs）的类。

可以说我正在测试该SaveStrings()方法。->我将命名测试CanSaveStrings()。

当我运行此测试时，它将显示以下标题：

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

我认为这很好地告诉了我，它正在测试什么。

当然，在英语中名词“ Tests”与动词“ tests”相同是有用的。

在命名测试时，您的创造力没有限制，因此我们可以为它们获得完整的句子标题。

通常，测试名称必须以动词开头。

示例包括：

• 检测（例如DetectsInvalidUserInput）
• 抛出（例如ThrowsOnNotFound）
• 会（例如WillCloseTheDatabaseAfterTheTransaction）

等等

另一种选择是使用“ that”代替“ if”。

后者可以节省我的击键次数，并且可以更准确地描述我在做什么，因为我不知道存在已测试的行为，但正在测试是否存在。

[ 编辑 ]

在使用上述命名约定一段时间之后，我发现在使用接口时，If前缀可能会造成混淆。碰巧的是，测试类IfSerializer.cs看起来与“打开文件”选项卡中的接口ISerializer.cs非常相似。在测试，要测试的类及其接口之间来回切换时，这可能会很烦人。结果我现在会选择这比如果作为前缀。

另外，我现在只在测试类中使用方法（因为在其他任何地方都不被视为最佳实践），因此使用“ _”来分隔测试方法名称中的单词，如下所示：

[Test] public void detects_invalid_User_Input()

我发现这更容易阅读。

[ 结束编辑 ]

我希望这能产生更多的想法，因为我认为命名测试非常重要，因为它可以为您节省大量时间，否则这些时间会花在尝试理解测试的功能上（例如，在长时间的中断后恢复项目） 。

在VS + NUnit中，我通常在项目中创建文件夹以将功能测试分组在一起。然后，我创建单元测试夹具类，并以要测试的功能类型命名。[Test]方法的命名方式Can_add_user_to_domain如下：

- MyUnitTestProject   
  + FTPServerTests <- Folder
   + UserManagerTests <- Test Fixture Class
     - Can_add_user_to_domain  <- Test methods
     - Can_delete_user_from_domain
     - Can_reset_password

我应该补充说，一旦准备好部署测试，而不必执行大量排除模式，则将测试保留在相同的程序包中，但与被测试源的并行目录中，可以消除代码的膨胀。

我个人喜欢《 JUnit Pocket Guide》中描述的最佳实践……很难击败JUnit的合著者写的书！

Foo类的测试用例的名称应为FooTestCase或类似的名称（FooIntegrationTestCase或FooAcceptanceTestCase）-因为它是一个测试用例。请参阅http://xunitpatterns.com/了解一些标准命名约定，例如测试，测试用例，测试夹具，测试方法等。