0

在我们的开发中，我们使用 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”，它们是什么类型的测试？它们必须是“单元测试”吗？使用“验收规范”来推动实施是一种好习惯吗？

4

3 回答 3

1

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

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

如果您可以想象在另一个世界中，整个手动 QA 部门以某种方式被封闭在一个时间场中，这允许他们在外部观察者的一秒钟内完成数小时的手动测试，那么这些手动测试可以用作对那些外部观察者进行 TDD 测试。（虽然测量代码覆盖率会很困难......）

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

于 2014-10-17T15:04:01.987 回答
1

我想澄清一下，在规范 2 中，术语“接受”和“单元”更多地指的是“风格”而不是活动。

我之所以这样命名“验收规范”，是因为它们允许您以“验收”文档所共有的风格表达自己，非开发人员应该很容易阅读（也就是说，不会被太多的代码弄得乱七八糟）。

另一方面，“单元规范”以编写单元测试的人更熟悉的风格表达。

但我根本不认为这个教派是规定性的。您可以自由选择您喜欢的任何风格，我经常使用“验收”风格进行单元测试！

于 2014-10-17T22:45:41.733 回答
1

TDD 对测试类型没有规定。您编写测试来指定/探索，然后将其用作回归工具。因此，如果您需要指定一个工作单元，您可能会编写一个单元测试。如果你需要指定一个完整的系统，你可能会在系统外部编写测试，你不会称之为单元测试。

请注意，“单位”一词实际上取决于您的观点。即使执行了大量代码，也可以将描述功能单元的测试视为单元测试。

于 2014-10-17T18:38:58.810 回答