单元测试有哪些流行的命名约定？ [关闭]

Question

一般

• 所有测试都遵循相同的标准。
• 清楚每个测试状态是什么。
• 具体说明预期行为。

示例

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

来源：Naming standards for Unit Tests

2) 用下划线分隔每个单词

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

其他

• 以 Test 结束方法名称
• 以类名开头的方法名

Answer 1

我倾向于使用MethodName_DoesWhat_WhenTheseConditions 的约定，例如：

Sum_ThrowsException_WhenNegativeNumberAs1stParam

但是，我确实看到很多是让测试名称遵循单元测试结构

• 安排
• 行动
• 断言

也遵循 BDD / Gherkin 语法：

• 给定
• 何时
• 那么

将以如下方式命名测试：UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

你的例子：

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

但是我更喜欢将要测试的方法名称放在第一位，因为这样测试可以按字母顺序排列，或者按字母顺序显示在 VisStudio 的成员下拉框中，并且 1 方法的所有测试都组合在一起。

---

无论如何，我喜欢用下划线分隔测试名称的主要部分，而不是每个单词，因为我认为它更易于阅读和了解测试的重点。

换句话说，我喜欢：Sum_ThrowsException_WhenNegativeNumberAs1stParam 优于 Sum_Throws_Exception_When_Negative_Number_As_1st_Param。

Answer 2

这也值得一读：Structuring Unit Tests

该结构对每个被测试的类都有一个测试类。这不是那么不寻常。但对我来说不同寻常的是，他为每个正在测试的方法都有一个嵌套类。

例如

using Xunit;

public class TitleizerFacts
{
    public class TheTitleizerMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void Name_AppendsTitle()
        {
            // Test code
        }
    }

    public class TheKnightifyMethod
    {
        [Fact]
        public void NullName_ReturnsDefaultTitle()
        {
            // Test code
        }

        [Fact]
        public void MaleNames_AppendsSir()
        {
            // Test code
        }

        [Fact]
        public void FemaleNames_AppendsDame()
        {
            // Test code
        }
    }
}

原因如下：

一方面，这是保持测试井井有条的好方法。所有的 方法的测试（或事实）组合在一起。例如，如果 您使用 CTRL+M、CTRL+O 快捷键折叠方法体，您可以 轻松扫描您的测试并像阅读代码规范一样阅读它们。

我也喜欢这种方法：

MethodName_StateUnderTest_ExpectedBehavior

所以也许适应：

StateUnderTest_ExpectedBehavior

因为每个测试都已经在一个嵌套类中

Answer 3

我对测试命名空间、类和方法使用“T”前缀。

我尽量保持整洁并创建复制命名空间的文件夹，然后为测试创建一个测试文件夹或单独的项目，并为基本测试复制生产结构：

AProj
   Objects
      AnObj
         AProp
   Misc
      Functions
         AFunc
   Tests
      TObjects
         TAnObj
            TAnObjsAreEqualUnderCondition
      TMisc
         TFunctions
            TFuncBehavesUnderCondition

我可以很容易地看出某事是一个测试，我确切地知道它属于哪个原始代码，（如果你不能解决这个问题，那么无论如何测试都太复杂了）。

它看起来就像接口命名约定，（我的意思是，你不会对以“I”开头的东西感到困惑，也不会与“T”混淆）。

不管有没有测试，编译都很容易。

不管怎样，理论上还是不错的，对于小型项目也很有效。

Answer 4

我确实像使用“PascalCasing”的其他方法一样命名我的测试方法，没有任何下划线或分隔符。我将后缀 Test 留给该方法，因为它没有增加任何价值。该方法是测试方法由属性TestMethod指示。

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

由于每个 Test 类应该只测试一个其他类，我将类的名称留在方法名称之外。包含测试方法的类的名称与被测类类似，后缀为“Tests”。

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

对于测试异常或不可能的操作的方法，我在测试方法前加上单词Cannot。

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

我的命名约定基于 Bryan Cook 的文章 "TDD Tips: Test Naming Conventions & Guidelines"。我发现这篇文章很有帮助。

Answer 5

我非常赞同这个人。您使用的命名约定是：

• 清楚每个测试状态是什么。
• 关于预期行为的具体说明。

测试名称还需要什么？

与Ray's answer 相反，我认为 Test 前缀是不必要的。这是测试代码，我们知道。如果你需要这样做来识别代码，那么你有更大的问题，你的测试代码不应该和你的生产代码混在一起。

至于长度和下划线的使用，它的测试代码，谁在乎呢？只有你和你的团队会看到它，只要它是可读的，并且清楚测试在做什么，继续！ :)

也就是说，我对测试还是很陌生，blogging my adventures with it :)

Answer 6

第一组名称对我来说更具可读性，因为 CamelCasing 分隔单词，而下划线分隔命名方案的各个部分。

我也倾向于在某处包含“Test”，无论是在函数名中，还是在封闭的命名空间或类中。

Answer 7

只要你遵循一个单一的做法，这并不重要。通常，我为一个方法编写一个单元测试，涵盖一个方法的所有变体（我有简单的方法；），然后为需要它的方法编写更复杂的测试集。因此，我的命名结构通常是 test（JUnit 3 的保留）。