单元测试命名最佳实践

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

这是在SO之前讨论过的，在单元测试中有哪些流行的命名约定？

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

然后，在我的测试类中，我使用方法，包括我正在测试的方法的名称，下划线，然后是情况和我期望发生的情况，例如Save_ShouldThrowExceptionWithNullName() 。

---

我喜欢Roy Osherove的命名策略，如下所示：

[UnitOfWork__StateUnderTest__ExpectedBehavior]

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

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

对于程序集，我使用典型的.Tests结尾，我认为这是相当普遍的，对于类（以Tests结束）是相同的：

[NameOfTheClassUnderTestTests]

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

---

我喜欢按照“应该”命名标准进行测试，同时在测试装置（即课程）之后命名测试夹具。

为了说明（使用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的单元测试库。

更新（4年后...）

对于那些感兴趣的人来说，我的命名测试方法已经发展多年。 我在上面描述的Should模式中的一个问题是，一眼看出哪种方法正在测试中并不容易知道。 对于OOP，我认为用被测方法启动测试名称更有意义。 对于设计良好的类，这应该导致可读的测试方法名称。 我现在使用类似于<method>_Should<expected>_When<condition>的格式。 很显然，根据上下文，你可能想用Should / When动词替代更适合的东西。 示例： Deposit_ShouldIncreaseBalance_WhenGivenPositiveValue()

---

我喜欢这种命名风格：

OrdersShouldBeCreated();
OrdersWithNoProductsShouldFail();

等等。 这对非测试者来说真的很清楚问题是什么。

链接地址: http://www.djcxy.com/p/21401.html

上一篇: Unit test naming best practices

下一篇: What is a reasonable code coverage % for unit tests (and why)?