我对rspec [Ruby]和specs [Scala]有点熟悉。星期六我通过了Cucumber的导师。我不喜欢Cucumber的是除了描述场景之外（就像你将使用spec或xUnit样式的测试一样），你必须实现额外的间接层：将场景步骤转换为ruby表达式。对我来说，创建不必要的（？）额外的间接层感觉就像“重量级”的J2EE方式，而不是像“轻量级”的ruby方式。 “领域专家”的可理解性是黄瓜的唯一优势吗？或者开发人员/测试人员是否也有一些非显而易见的（技术？）优势？
答案 0 :(得分：6)
Cucumber旨在通过协作创建每个人都能理解的场景，帮助业务利益相关者改进开发人员和测试人员对系统的理解。
吸引业务利益相关者的行为得到回报，因为每个人都能更好地理解，他们开始分享相同的语言，并将该语言带入代码中（参见领域驱动设计的“无处不在的语言”），这可以带来更好的估计，欣赏范围，围绕实现相同目标的选项的对话等等。
当然还有其他方法可以实现目标。例如，在我们的C＃项目中，我们通过场景进行讨论，将它们写在维基上，然后使用一些自定义的域特定语言来实现它们，而不是this one。同样的事情可以在Ruby中完成。
BDD是学习我们认为我们知道自己在做什么的地方的过程，但事实证明我们错了 - discovery of ignorance。使用Feature Injection和单元级示例，这会发生在多个粒度级别，一直到项目愿景本身。它倾向于为自己付出代价，但你不需要BDD框架来做BDD 。
BDD中的对话是重要的部分，而不是用于捕获它们的工具（我帮助编写JBehave并仍然认为这是真的）。自动化回归测试对于减少随着代码库增长而增加的手动工作也很重要，而Cucumber，DSL和其他BDD工具为您提供了一个非常好的副产品，它也可以帮助您跟踪和驱逐共享的理解
编辑：我应该提到步骤的重用也很重要，但无论是使用BDD框架还是使用DSL，它都没有多大区别。它确实在DSL之间产生差异，并且只是在程序上模仿每个用户的交互。
答案 1 :(得分：6)
利益相关者可以阅读和理解黄瓜验收规范当然是一个关键优势，但仅凭这一事实并不能真正实现黄瓜的实惠。随着为他们完成的工作贯穿团队开发周期的价值流，您的功能和方案应该在某种程度上有所增长。
有些团队可能会让分析师在周期开始时确定工作范围。有时这位分析师会写出小黄瓜验收规范，但是无论谁写了初稿，你都会期望它们的粒度相当粗糙。他们可能无法涵盖所有不快乐的道路。
当开发人员开始工作时，他们经常会发现边缘情况和丢失的情况。此时，他们可以与分析师联系，并将这些对话的结果写入黄瓜特征。
根据我的经验，测试人员培养出更加批判的眼光，因此看到他们添加更多场景和功能并不罕见。测试人员也可能发现缺陷，这些缺陷应该添加到cukes中以保护我们免于回归。
关键是，除了为我们的代码提供可执行文档之外，Cucumber还提供了一个存储库，用于了解团队对话的状态以及正在开发的功能。
所有这一切都有额外的开销。但是，值得考虑的是团队流程中已经有多少开销，Cucumber可能会为此简化流程。我发现Cucumber有助于减少团队室内外通信中发生的捶打量。
我还应该提到黄瓜是用于全堆验收测试，因此相对于单元测试，黄瓜应该不那么精细。黄瓜不是单元和集成测试的良好替代品。我也绝不会建议使用黄瓜来验证应用UI的审美方面。只需使用它来验证用户在使用您的应用时可能采取的操作。
答案 2 :(得分：2)
这取决于你想要达到的目标。
Cucumber增加了开销，可能很难习惯，需要时间掌握。
如果您希望您的域专家能够阅读您的测试，那么您一定要试一试。
另一方面，如果开发人员是唯一阅读测试的人，那么你可能会坚持使用rspec / unit-test /等。并在这些框架中编写集成测试。但是，您可以使用黄瓜实现更具可读性的高级文档。 请参阅黄瓜中的rspec 2 core功能说明。