Question

在我们的开发中，我们使用TDD，所以我们有一些这样的测试：

"User" should {
  "return 'Mike' if its name is 'Mike'" in {
      val user = User("Mike")
      user.getName === "Mike"
  }
  "return 20 if its age is 20" in {
    val user = User(age = Some(20))
    user.getAge === Some(20)
  }
}

我们在这里写的测试看起来像“单元测试”。

然后我发现specs2提供了另一种更易于表达的语法，我感兴趣的是：

def is = s2"""
   User can have name and age, and we have ways to get them, say, if we have a user whose name is "Mike" and the age is "20",
     - we can the name "Mike" [$e1]
     - also can get the age 20 [$e2]
"""
def e1 = {
  val user = User("Mike")
  user.getName === "Mike"
}
def e2 = {
  val user = User(age = Some(20))
  user.getAge === Some(20)
}

我想用TDD尝试一下，但很快我发现这种测试是“验收规范”。我脑海里浮现出一个强烈的问题：

如果我们提到“TDD”，他们会进行什么样的测试？它们必须是“单元测试”吗？使用“验收规范”来推动实施是不错的做法？

Answer 1

我不认为TDD严格要求对单元测试的特定定义＆＃34;与任何其他类型的测试。测试的特定种只是一个实现细节。 TDD关注的重点是这些测试的可重复性，以便为开发工作提供快速反馈。 TDD并不一定关心它们是什么类型的测试，它只关心使用这些测试来推动系统的开发。

为此，任何可以快速重复执行的测试（作为红色/绿色/重构周期的一部分）都可以以TDD风格推动开发。

如果你可以想象一个替代的世界，在某个时间段，整个手动QA部门被封闭在一个时空领域，这允许他们在一秒钟内对外部观察者进行数小时的手动测试，那些手动测试可以用作外部观察员的TDD测试。（虽然测量代码覆盖率很难......）

可以快速执行的任何详尽的可重复测试都可以用于TDD。

Answer 2

TDD并不是关于测试类型的规定。您编写测试以指定/探索，然后将其用作回归线束。因此，如果您需要指定一个工作单元，您可能会编写一个单元测试。如果您需要指定整个系统，您可能会在系统外部编写测试，而不会将其称为单元测试。

注意术语＆＃34;单位＆＃34;真的取决于你的观点。即使执行了大量代码，也可以将单元测试视为描述功能单元的测试。

Answer 3

我想在规范2中澄清条款＆＃34; Acceptance＆＃34;和＆＃34;单位＆＃34;更多地了解＆＃34;款式＆＃34;而不是活动。

我将＆＃34;验收规范命名为＆＃34;因为它们允许你以一种常见的方式来表达自己的接受＆＃34;非开发人员应该易于阅读的文档（也就是说，没有太多代码混乱）。

另一方面＆＃34;单位规格＆＃34;正在以一种对编写单元测试更熟悉的风格表达。

但我并不认为这种名称是开处方的。您可以自由选择您喜欢的任何风格，我经常使用＆＃34; Acceptance＆＃34;单元测试的风格！

它是什么样的测试＆＃34; TDD＆＃34;？

3 个答案: