更新（2021 年 7 月）

自从我最初的答案（将近 12 年）和最佳实践在此期间发生了很大变化以来，已经有一段时间了。所以我倾向于更新我自己的答案，并为读者提供不同的命名策略。

许多评论和答案指出，我在原始答案中提出的命名策略并不抗拒重构，最终导致难以理解的名称，我完全同意。

在过去的几年里，我最终使用了一种更易于阅读的命名模式，其中测试名称描述了我们想要测试的内容，正如Vladimir
Khorikov所描述的那样。

一些例子是：

• Add_credit_updates_customer_balance
• Purchase_without_funds_is_not_possible
• Add_affiliate_discount

但正如您所看到的，它是一个非常灵活的模式，但最重要的是，阅读名称您就知道测试是关于什么的，而不包括可能随时间变化的技术细节。

为了命名项目和测试类，我仍然坚持原来的答案模式。

原始答案（2009 年 10 月）

我喜欢Roy Osherove 的命名策略。如下：

[UnitOfWork_StateUnderTest_ExpectedBehavior]

它具有方法名称和结构化方式所需的所有信息。

工作单元可以小到单个方法、一个类，也可以大到多个类。它应该代表所有要在这个测试用例中测试并在控制之下的东西。

对于程序集，我使用典型的.Tests结尾，我认为这种结尾非常普遍，并且对于类也是如此（以 结尾Tests）：

[NameOfTheClassUnderTestTests]

之前我是用Fixture作为后缀而不是Tests，但我觉得后者更常见，于是我改变了命名策略。