单元测试命名最佳实践

Question

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

这在 SO 之前讨论过，在单元测试的一些流行命名约定是什么？

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

在我的测试类中，我有方法，其中包含我正在测试的方法的名称、下划线，然后是情况和我期望发生的情况，例如Save_ShouldThrowExceptionWithNullName() 。

Answer 1

更新（2021 年 7 月）

自从我的原始答案（将近 12 年）和最佳实践在此期间发生了很大变化以来已经有一段时间了。 所以我倾向于更新我自己的答案，并为读者提供不同的命名策略。

很多评论和回答都指出，我在原答案中提出的命名策略不抗重构，最终以难以理解的名称结束，我完全同意。

在过去的几年里，我最终使用了一个更易读的命名模式，其中测试名称描述了我们想要测试的内容，在Vladimir Khorikov描述的行中。

一些例子是：

• Add_credit_updates_customer_balance
• Purchase_without_funds_is_not_possible
• Add_affiliate_discount

但是正如您所看到的，这是一个非常灵活的模式，但最重要的是，阅读名称您就知道测试的内容，而无需包含可能随时间变化的技术细节。

为了命名项目和测试类，我仍然坚持原始答案模式。

原始答案（2009 年 10 月）

我喜欢Roy Osherove 的命名策略。 这是以下内容：

[UnitOfWork_StateUnderTest_ExpectedBehavior]

它以结构化的方式包含有关方法名称的所有信息。

工作单元可以小到单个方法、一个类，也可以大到多个类。 它应该代表在这个测试用例中要测试的所有东西，并在控制之下。

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

[NameOfTheClassUnderTestTests]

之前我用Fixture作为后缀而不是Tests，但我觉得后者更常见，于是我改变了命名策略。

Answer 2

我喜欢跟着“应该”做检查命名标准，而本机后命名的测试夹具测试（即类）。

举例说明（使用 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年后...）

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

Answer 3

我喜欢这种命名风格：

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

等等。 它让非测试人员非常清楚问题是什么。

Answer 4

肯特贝克建议：

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

   [name of your 'unit']Tests

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

   test[feature being tested]

例如，有以下类：

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

    // other methods and properties
}

测试夹具将是：

class PersonTests {

    testAgeCalculationWithNoBirthDate() { ... }

    // or

    testCalculateAge() { ... }
}

Answer 5

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

“单位”在域中也经常使用。 例如MeasurementUnit 。 一个名为MeasurementUnitTest的类是“Measurement”还是“MeasurementUnit”的测试？

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

命名空间。 我在 C# 中工作，并将我的测试类保存在与它们正在测试的类相同的命名空间中。 这比拥有单独的测试命名空间更方便。 当然，测试类在不同的项目中。

测试方法名称。 我喜欢将我的方法命名为 WhenXXX_ExpectYYY。 它使前提条件清晰，并有助于自动化文档（a la TestDox）。 这类似于 Google 测试博客上的建议，但更多地分离了先决条件和期望。 例如：

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

Answer 6

我使用Given-When-Then概念。 看看这篇短文http://cakebaker.42dh.com/2009/05/28/given-when-then/ 。 文章根据 BDD 描述了这个概念，但您也可以在 TDD 中使用它而无需任何更改。

Answer 7

我最近提出了以下约定来命名我的测试、它们的类和包含项目，以最大化它们的描述性：

假设我正在MyApp.Serialization命名空间中的一个项目中测试Settings类。

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

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

假设我正在测试SaveStrings()方法。 -> 我将测试命名为CanSaveStrings() 。

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

MyApp.Serialization.Tests.IfSettings.CanSaveStrings

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

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

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

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

例子包括：

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

等等。

另一种选择是使用“that”而不是“if”。

后者为我节省了击键，但并介绍更多的正是我做的，因为我不知道，所测试的行为是存在的，但正在测试，如果它是。

[编辑]

在使用上述命名约定一段时间后，我发现在使用接口时， If前缀可能会令人困惑。 碰巧的是，测试类IfSerializer.cs看起来与“打开文件选项卡”中的接口ISerializer.cs非常相似。 当在测试、被测试的类及其接口之间来回切换时，这会变得非常烦人。 因此，我现在会选择That over If作为前缀。

此外，我现在使用 - 仅用于我的测试类中的方法，因为它不被认为是其他任何地方的最佳实践 - 用“_”分隔我的测试方法名称中的单词，如下所示：

[Test] public void detects_invalid_User_Input()

我觉得这更容易阅读。

[结束编辑]

我希望这会产生更多的想法，因为我认为命名测试非常重要，因为它可以为您节省大量时间，否则您将花费​​大量时间来尝试了解测试正在做什么（例如，在长时间中断后恢复项目之后） .

Answer 8

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

对于测试方法名称，我个人发现使用冗长和自记录的名称非常有用（以及进一步解释测试正在做什么的 Javadoc 注释）。

Answer 9

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

Answer 10

在 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

Answer 11

我应该补充一点，将您的测试保存在同一个包中，但在与被测试源的并行目录中，一旦您准备好部署它，就可以消除代码的膨胀，而无需执行一堆排除模式。

我个人喜欢“JUnit 袖珍指南”中描述的最佳实践……很难打败 JUnit 的合著者写的一本书！

Answer 12

Foo 类的测试用例的名称应该是 FooTestCase 或类似的东西（FooIntegrationTestCase 或 FooAcceptanceTestCase）——因为它是一个测试用例。 有关一些标准命名约定，如测试、测试用例、测试夹具、测试方法等，请参见http://xunitpatterns.com/ 。