BDD能带来回报吗？

Question

我对rspec Ruby和Scala规范比较熟悉。昨天我给黄瓜请了一位家教。我不喜欢Cucumber的地方在于，除了描述场景(就像使用spec或xUnit风格的测试一样)之外，还必须实现额外的间接层:将场景步骤转换为ruby表达式。对于我创建不必要的(?)额外的间接层感觉像是“重量级”J2EE方式，而不是“轻量级”ruby方式。“领域专家”的理解能力是Cucumber的唯一优势吗？还是有一些不明显的(技术上的？)对开发人员/测试人员也有好处吗？

Answer 1

从实际的角度来看，BDD与TDD是高度同义的。Rspec是一个BDD测试框架，和Cucumber一样。

利益相关者可以阅读和理解Cucumber接受规范肯定是一个关键优势，但仅凭这一事实并不能真正获得Cucumber的真正好处。当为您的功能和场景所做的工作在您的团队开发周期的价值流中移动时，您的功能和场景应该在某种程度上增长。

一些团队可能会有一个分析师在周期开始时确定工作的范围。有时，这位分析师会编写小黄瓜验收规范，但无论是谁写的第一个草案，您都会认为它们是相当粗粒度的。它们可能不会覆盖每一条不愉快的道路。

当开发人员开始工作时，他们经常发现边缘情况和缺失的场景。在这一点上，他们可以与分析师取得联系，这样的对话结果应该写入黄瓜特征中。

在我的经验中，测试人员已经培养了更多的批判性眼光，因此看到他们添加更多的场景和功能并不少见。测试人员还可能发现缺陷，这些缺陷应该添加到cukes中，以保护我们免受回归。

关键是，除了为我们的代码提供可执行文档之外，Cucumber还提供了一个存储库，用于存储团队与正在开发的功能之间的对话状态。

当然，所有这些都有额外的开销。然而，值得考虑的是，您的团队流程中已经有多少开销，Cucumber可能会用来简化。我发现Cucumber有助于减少在团队房间内外关于功能的交流中发生的混乱。

我还应该提到，cucumber旨在作为全栈验收测试，因此相对于您的单元测试，应该不那么细粒度。而且cucumber不是单元测试和集成测试的好替代品。我也永远不会推荐使用cucumber来验证你的应用程序UI的美学方面。只需使用它来验证用户在使用您的应用程序时可能采取的操作。

Answer 2

Cucumber旨在通过协作创建每个人都能理解的场景，帮助业务利益相关者改进开发人员和测试人员对系统的理解。

让业务干系人参与的行为是值得的，因为每个人都得到了更好的理解，他们开始共享相同的语言，并将这种语言带入代码中(请参见域驱动设计的“无处不在的语言”)，这可以导致更好的估计，对范围的欣赏，围绕实现相同目标的选项的对话，等等。

当然，还有其他方法可以实现这些目标。例如，在我们的C#项目中，我们讨论了这些场景，在wiki上编写它们，然后使用一种类似于this one的自定义领域特定语言来实现它们。同样的事情也可以在Ruby中完成。

BDD是学习我们认为我们知道自己在做什么的地方的过程，但事实证明我们错了- discovery of ignorance。对于Feature Injection和单元级别的示例，这发生在多个粒度级别，一直到项目愿景本身。它往往会为自己带来回报，但你不需要一个BDD框架来做BDD。

BDD中的对话是重要的部分，而不是您用来捕获它们的工具(我帮助编写了JBehave，并且仍然相信这是真的)。自动化回归测试对于减少随着代码库的增长而增加的手动工作也很重要，Cucumber、DSL和其他BDD工具为您提供了一个非常好的副产品，它还可以帮助您跟踪和驱动共享的理解。

我应该提一下，步骤的重用也很重要，但是无论你是使用框架还是使用框架，这都没有太大的区别。它确实造成了DSL和只是程序化地模拟每个用户交互之间的区别。

Answer 3

这取决于你想要实现什么。

黄瓜增加了开销，可能很难习惯，需要时间来掌握。

如果你想让你的领域专家能够阅读你的测试，你绝对应该试一试。

另一方面，如果只有开发人员阅读您的测试，那么您可以坚持使用rspec/unit-test/等，并在这些框架中编写集成测试。但是，使用cucumber可以获得更具可读性的高级文档。参见cucumber中的rspec 2 core功能描述。