Question

我不小心偶然发现了Luke Redpath的旧版article，它提供了一个非常简单的BDD示例（非常简短，即使对于像我这样的非Ruby程序员也很容易理解）。我发现最终结果非常不完整，因此使这个例子毫无用处。

最终结果是单个测试，用于验证具有预设属性的用户是否有效。在我看来，这还不足以正确验证验证规则。例如，如果您更改

validates_length_of :password, :in => 6..12, :allow_nil => :true

到

validates_length_of :password, :in => 7..8, :allow_nil => :true

（甚至完全删除密码长度验证）测试仍然会通过，但您显然可以看到代码现在违反了初始要求。

我只是认为将所有单个测试放入单个测试的最后一次重构是不够的。他只测试了不能保证太多的“快乐路径”。我绝对会有所有测试验证是否使用某些值触发了正确的错误。在密码的情况下，我将测试长度小于6且大于12的密码无效并触发相应的错误。 “快乐路径”测试也会出现在那里，但并不是单独出现在文章中。

你有什么看法？我只想弄清楚为什么这个人按照他做的方式做到了，他是否只是忽略了问题，或者是他的意图。我可能会遗漏一些东西。

Answer 1

我不太明白你的问题。规范做包含对密码长度的期望，对于快乐路径和两种不同的失败模式（密码太长，密码太短）：

specify "should be valid with a full set of valid attributes" do
  @user.attributes = valid_user_attributes
  @user.should_be_valid
end

由于valid_user_attributes包含有效密码，因此需要处理幸福路径。

specify "should be invalid if password is not between 6 and 12 characters in length" do
  @user.attributes = valid_user_attributes.except(:password)
  @user.password = 'abcdefghijklm'
  @user.should_not_be_valid
  @user.password = 'abcde'
  @user.should_not_be_valid
end

这测试了两种失败模式。

当然，缺少一个边界情况（12个字符），但这并不算太糟糕。

Answer 2

我没有时间阅读这篇文章，因此我无法验证您的声明，但我认为一般的答案是，如果密码验证规则是具体要求，则应使用一个或多个进行验证测试该特定要求（至少每个“部分”要求）。

Answer 3

BDD（和TDD）是设计活动。这些测试旨在推动代码的设计，而不是保证它完全没有错误。应该有独立的测试人员。所以我们需要一定程度的覆盖，以确保我们的代码按预期工作并以干净的方式处理异常。但是TDD并不要求我们为每个可以想象的边缘情况编写单元测试。

关于你引用的具体例子，也许他应该编写两个测试，一个密码为六个字符，一个密码为十二个字符。但重点是什么？我们知道要求是密码长度必须在6到12个字符之间。如果我们误解了要求并认为规则应该是......

validates_length_of :password, :in => 7..8, :allow_nil => :true

...然后我们将编写我们的测试数据进行测试，通过我们错误的解释。因此，编写更多测试只会给我们带来错误的信心。这就是为什么TDD和BDD的支持者也喜欢其他XP技术，如配对编程：捕捉我们在单元测试中引入的错误。

同样，我们可以完全删除验证密码长度的测试，但重点是什么？这些测试可以帮助我们正确地实现分类。如果我们没有对我们编写的每一段代码进行测试，那么我们就不会进行TDD / BDD。

一个BDD的例子 - 为什么只测试“快乐路径”？

3 个答案: