一般

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

例子

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结束方法名 用类名开始方法名


当前回答

只要你坚持一个练习,这并不重要。通常,我为一个方法编写一个单元测试,它涵盖了该方法的所有变化(我有简单的方法;),然后为需要它的方法编写更复杂的测试集。因此,我的命名结构通常是test(从JUnit 3保留下来的)。

其他回答

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

结构中每个被测试的类都有一个测试类。这并不罕见。但对我来说不同寻常的是,他为每个被测试的方法都有一个嵌套类。

e.g.

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

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

只要你坚持一个练习,这并不重要。通常,我为一个方法编写一个单元测试,它涵盖了该方法的所有变化(我有简单的方法;),然后为需要它的方法编写更复杂的测试集。因此,我的命名结构通常是test(从JUnit 3保留下来的)。

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

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

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

我可以很容易地看出某些东西是一个测试,我确切地知道它属于什么原始代码,(如果你不能解决这个问题,那么这个测试就太复杂了)。

它看起来就像接口命名约定,(我的意思是,你不会混淆以“I”开头的东西,也不会混淆以“T”开头的东西)。

使用测试或不使用测试都很容易编译。

无论如何,这在理论上是很好的,并且对于小型项目非常有效。

第一组名称对我来说可读性更强,因为camel套管分隔了单词,下划线分隔了命名方案的各个部分。

我还倾向于在函数名或外围名称空间或类中包含“Test”。

我倾向于使用MethodName_DoesWhat_WhenTheseConditions的约定,例如:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

然而,我所看到的是使测试名称遵循的单元测试结构

安排 行为 断言

它也遵循BDD / Gherkin语法:

鉴于 当 然后

这将是命名测试的方式:UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

对于你的例子:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

然而,我更喜欢把测试的方法名放在前面,因为这样测试就可以按字母顺序排列,或者在VisStudio的成员下拉框中按字母顺序排列,并且一个方法的所有测试都被分组在一起。


在任何情况下,我喜欢用下划线分隔测试名称的主要部分,而不是每个单词,因为我认为这样更容易阅读和理解测试的要点。

换句话说,我更喜欢:Sum_ThrowsException_WhenNegativeNumberAs1stParam,而不是sum_throw_exception_when_negative_number_as_1st_param。