1) 方法名_被测试状态_期望的行为
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 ()
我非常赞同你的想法。你所使用的命名约定如下：
从测试名称中，你还需要什么呢？
与Ray's answer相反，我认为不需要在前面添加Test前缀。这是测试代码，我们都知道。如果你需要这样做来识别代码，那你有更大的问题，你的测试代码不应该混杂在生产代码中。
至于长度和下划线的使用，这是测试代码，谁会在乎呢？只有你和你的团队会看到它，只要它可读并且清楚地说明了测试正在做什么，就可以继续！ :)
话虽如此，我对测试还是很新，也在博客上记录我的经历 :)
这也值得一读：单元测试结构
该结构每个被测试类都有一个测试类，这并不罕见。但对我来说不寻常的是，他为每个被测试方法都有一个嵌套类。
例如：
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
因为每个测试已经在一个嵌套类中了。
我倾向于使用以下命名规则：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。
我像命名其他方法一样使用“帕斯卡命名法”来命名我的测试方法，没有下划线或分隔符。我留出方法后缀Test，因为它没有添加任何价值。通过属性TestMethod指示该方法是一个测试方法。
[TestMethod]
public void CanCountAllItems() {
// Test the total count of items in collection.
}
[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技巧：测试命名约定和指南”。我发现这篇文章非常有帮助。
对我来说，第一组名称更易读，因为CamelCasing将单词分开，而下划线则分隔了命名方案的各个部分。
我也倾向于在函数名称或封闭的命名空间或类中包含“Test”。
我在测试命名空间、类和方法中使用“T”前缀。
我尽量保持整洁，创建复制命名空间的文件夹，然后为测试创建一个测试文件夹或单独的项目，并为基本测试复制生产结构：
AProj
Objects
AnObj
AProp
Misc
Functions
AFunc
Tests
TObjects
TAnObj
TAnObjsAreEqualUnderCondition
TMisc
TFunctions
TFuncBehavesUnderCondition
我可以轻松地看出某些东西是一个测试，我知道它所涉及的原始代码是什么（如果你无法弄清楚，那么这个测试本来就太复杂了）。
它看起来就像接口命名约定一样（我的意思是，你不会因为以'I'开头的事物而感到困惑，也不会因为'T'而感到困惑）。
很容易只编译带或不带测试。
理论上来说很好，对于小项目来说效果还不错。