我认为最重要的事情之一是保持命名约定的一致性(并与团队的其他成员一致)。很多时候，我看到在同一个项目中使用了大量不同的约定。

在VS + NUnit中，我通常在项目中创建文件夹，将功能测试分组在一起。然后我创建单元测试fixture类，并以我正在测试的功能类型命名它们。[Test]方法按照Can_add_user_to_domain命名:

- MyUnitTestProject   
  + FTPServerTests <- Folder
   + UserManagerTests <- Test Fixture Class
     - Can_add_user_to_domain  <- Test methods
     - Can_delete_user_from_domain
     - Can_reset_password

类名。对于测试fixture名称，我发现“test”在许多领域的通用语言中非常常见。例如，在工程领域:应力测试，在化妆品领域:SkinTest。很抱歉不同意Kent的观点，但是在我的测试装置中使用“Test”(stress stesttest ?)是令人困惑的。

“单位”在域中也经常使用。例如MeasurementUnit。一个名为MeasurementUnitTest的类是“Measurement”或“MeasurementUnit”的测试吗?

因此，我喜欢对所有测试类使用“Qa”前缀。例如QaSkinTest和qammeasurementunit。它永远不会与域对象混淆，并且使用前缀而不是后缀意味着所有测试fixture在视觉上一起存在(如果您的测试项目中有假类或其他支持类，则非常有用)

名称空间。我使用c#工作，并且我将我的测试类保持在与它们所测试的类相同的命名空间中。这比使用单独的测试名称空间更方便。当然，测试类在不同的项目中。

测试方法名称。我喜欢命名我的方法WhenXXX_ExpectYYY。它使前提条件变得清晰，并有助于自动化文档(一种TestDox)。这类似于谷歌测试博客上的建议，但更多地分离了前提条件和期望。例如:

WhenDivisorIsNonZero_ExpectDivisionResult
WhenDivisorIsZero_ExpectError
WhenInventoryIsBelowOrderQty_ExpectBackOrder
WhenInventoryIsAboveOrderQty_ExpectReducedInventory

我认为最重要的事情之一是保持命名约定的一致性(并与团队的其他成员一致)。很多时候，我看到在同一个项目中使用了大量不同的约定。

我喜欢遵循测试的“Should”命名标准，同时以被测单元(即类)命名测试夹具。

为了说明(使用c#和NUnit):

[TestFixture]
public class BankAccountTests
{
  [Test]
  public void Should_Increase_Balance_When_Deposit_Is_Made()
  {
     var bankAccount = new BankAccount();
     bankAccount.Deposit(100);
     Assert.That(bankAccount.Balance, Is.EqualTo(100));
  }
}

为什么“应该”?

我发现它迫使测试编写人员用这样一句话来命名测试:“应该[处于某种状态][在动作发生之后/之前/当][发生时]”

是的，到处写“应该”确实有点重复，但正如我所说，它迫使作者以正确的方式思考(所以对新手来说很好)。此外，它通常会产生一个可读的英文测试名称。

更新:

我注意到Jimmy Bogard也是“should”的粉丝，他甚至有一个名为“should”的单元测试库。

更新(4年后…)

For those interested, my approach to naming tests has evolved over the years. One of the issues with the Should pattern I describe above as its not easy to know at a glance which method is under test. For OOP I think it makes more sense to start the test name with the method under test. For a well designed class this should result in readable test method names. I now use a format similar to <method>_Should<expected>_When<condition>. Obviously depending on the context you may want to substitute the Should/When verbs for something more appropriate. Example: Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

我应该补充一点，将您的测试放在同一个包中，但位于与被测试的源代码并行的目录中，一旦您准备好部署它，就可以消除代码的膨胀，而不必执行一堆排除模式。

我个人喜欢“JUnit Pocket Guide”中描述的最佳实践……很难有一本书比JUnit!