一般的

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

例子

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结束方法名称
• 以类名开头的方法名

解决方案

只要我们遵循一种练习，就没关系了。通常，我为一个方法编写一个单元测试，以涵盖该方法的所有变体(我有简单的方法；)，然后为需要该方法的方法编写更复杂的测试集。因此，我的命名结构通常是测试(来自JUnit 3的保留)。

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

我也倾向于在函数名称或者封闭的名称空间或者类中的某个地方包括"测试"。

在这个男人身上，我几乎和你在一起。我们使用的命名约定是：

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

我们还需要测试名称中的什么？

与Ray的答案相反，我认为Test前缀不是必需的。这是测试代码，我们知道。如果我们需要这样做来标识代码，那么我们会遇到更大的问题，因此不应将测试代码与生产代码混在一起。

至于下划线的长度和用途，其测试代码，到底谁在乎？只要我们和团队都能看到它，只要它可读且清楚测试的内容，那就继续吧！ :)

话虽如此，我仍然对使用冒险进行测试和撰写博客还很陌生:)

我确实像使用" PascalCasing"的其他方法一样命名测试方法，没有任何下划线或者分隔符。我将方法的后缀测试省去了，因为它没有任何价值。该方法是一种测试方法，由属性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
}

对于测试不可能的异常或者动作的方法，我在测试方法前加上"不能"一词。

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

我的命名会议基于Bryan Cook的文章" TDD技巧：测试命名约定和准则"。我发现这篇文章很有帮助。