unit-testing - 单元测试命名最佳实践

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

已关闭 1 年前。

已锁定。这个问题及其答案是 locked因为这个问题是题外话，但却具有历史意义。目前不接受新的答案或互动。

命名单元测试类和测试方法的最佳实践是什么？

之前在 What are some popular naming conventions for Unit Tests? 上讨论过这个问题

我不知道这是否是一个非常好的方法，但目前在我的测试项目中，我在每个生产类和测试类之间都有一对一的映射，例如Product和ProductTest .

在我的测试类中，我有一些方法，其中包含我正在测试的方法的名称、下划线，然后是情况和我期望发生的情况，例如Save_ShouldThrowExceptionWithNullName() .

Answer 1

更新(2021 年 7 月)

距离我最初的回答(近 12 年)已经过去了很长一段时间，在此期间最佳实践发生了很大变化。所以我倾向于更新自己的答案，为读者提供不同的命名策略。

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

在过去的几年里，我最终使用了一种更易于理解的命名模式，其中测试名称描述了我们想要测试的内容，在 Vladimir Khorikov 描述的行中.

一些例子是:

• Add_credit_updates_customer_balance
• Purchase_without_funds_is_not_possible
• Add_affiliate_discount

但正如您所看到的，它是一个非常灵活的架构，但最重要的是，阅读名称您就知道测试的内容，而无需包含可能随时间变化的技术细节。

为了命名项目和测试类，我仍然遵循原始答案架构。

原始答案(2009 年 10 月)

我喜欢Roy Osherove's naming strategy 。内容如下:

[UnitOfWork_StateUnderTest_ExpectedBehavior]

它以结构化方式包含方法名称所需的所有信息。

工作单元可以小到单个方法、一个类，也可以大到多个类。它应该代表此测试用例中要测试并受控制的所有事物。

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

[NameOfTheClassUnderTestTests]

之前我使用Fixture作为后缀而不是Tests，但我认为后者更常见，所以我改变了命名策略。