单元测试有哪些流行的命名约定？

Question

一般

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

例子

1)MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

资料来源:单元测试的命名标准

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

我和你在这一个人身上非常相似.您使用的命名约定是:

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

您还需要一个测试名称？

与Ray的回答相反,我不认为测试前缀是必要的.它是测试代码,我们知道.如果您需要这样做以识别代码,那么您遇到了更大的问题,您的测试代码不应与您的生产代码混淆.

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

也就是说,我仍然很擅长测试和博客我的冒险经历 :)

Answer 2

这也值得一读:构建单元测试

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

例如

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

我倾向于使用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 4

我使用"PascalCasing"命名我的测试方法,就像其他方法一样,没有任何下划线或分隔符.我将方法的postfix 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
}

对于测试不可能的异常或操作的方法,我在测试方法前加上单词Can not.

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

我的命名对话基于Bryan Cook 的文章"TDD提示:测试命名约定和指南".我发现这篇文章非常有帮助.

Answer 5

第一组名称对我来说更具可读性,因为CamelCasing将单词和下划线分开,命名方案的各个部分.

我也倾向于在函数名称或封闭的命名空间或类中包含"Test".