tdd - BDD有回报吗？

Question

我对 rspec [Ruby] 和 specs [Scala] 有点熟悉。昨天我通过了黄瓜的导师。我不喜欢 Cucumber 的地方在于，除了描述场景（就像您使用规范或 xUnit 样式测试所做的那样）之外，您还必须实现额外的间接层：将场景步骤转换为 ruby​​ 表达式。对我来说，创建不必要的（？）额外的间接层感觉就像“重量级”J2EE 方式，而不是“轻量级”红宝石方式。“领域专家”的可理解性是 Cucumber 的唯一优势吗？还是对开发人员/测试人员也有一些不明显的（技术？）优势？

Answer 1

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

吸引业务利益相关者的行为是有回报的，因为每个人都得到了更好的理解，他们开始共享相同的语言并将该语言携带到代码中（参见领域驱动设计的“普遍存在的语言”），这可以导致更好的估计、范围的评估、围绕实现相同目标的选项的对话等。

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

BDD 是学习我们认为知道自己在做什么的地方的过程，但事实证明我们错了——发现无知。使用功能注入和单元级示例，这发生在多个粒度级别，一直到项目愿景本身。它往往会收回成本，但您不需要 BDD 框架来执行 BDD。

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

编辑：我应该提一下，步骤的重用也很重要，但是无论您使用 BDD 框架还是 DSL 都没有太大区别。它确实在 DSL 和只是在程序上模仿每个用户交互之间有所不同。

Answer 2

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

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

一些团队可能会在周期开始时让分析师确定工作范围。有时这位分析师会编写小黄瓜验收规范，但无论谁编写初稿，您都会认为它们的粒度相当粗略。它们可能无法涵盖所有​​不愉快的路径。

随着开发人员开始工作，他们经常会发现边缘情况和缺失的场景。此时他们可以与分析师建立联系，并且此类对话的结果应写入黄瓜特征。

根据我的经验，测试人员培养了更加挑剔的眼光，因此看到他们添加更多场景和功能的情况并不少见。测试人员也可能会发现缺陷，这些缺陷应该被添加到杯子中以保护我们免于回归。

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

所有这些肯定有额外的开销。但是，值得考虑在您的团队的流程中已经有多少开销，Cucumber 可以用来简化这些开销。我发现 Cucumber 有助于减少团队室内外功能交流中发生的冲突。

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

Answer 3

这取决于您想要达到的目标。

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

如果您希望您的领域专家能够阅读您的测试，您绝对应该尝试一下。

另一方面，如果开发人员是唯一阅读您的测试的人，您可能会坚持使用 rspec/unit-test/etc。并在这些框架中编写您的集成测试。但是，您可以通过使用 cucumber 获得更易读的高级文档。例如，请参阅黄瓜中的rspec 2 核心功能描述。