tdd - BDD 有返回吗？

Question

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

Answer 1

从实用的角度来看，BDD 是 TDD 的高度同义词。 Rspec 是一个 BDD 测试框架，还有 Cucumber。

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

一些团队可能有一名分析师在周期开始时确定工作范围。有时，该分析师会编写小 cucumber 验收规范，但无论是谁编写了初稿，您都会期望它们的粒度相当粗略。它们可能不会涵盖每一条不愉快的道路。

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

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

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

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

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