unit-testing - RSpec 与 Cucumber(RSpec 故事)

Question

就目前情况而言，这个问题不太适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、民意调查或扩展讨论。如果您觉得这个问题可以改进并可能重新开放， visit the help center以获得指导。

已关闭 10 年前。

什么时候应该对 Rails 应用程序使用规范，什么时候应该使用 Cucumber(以前的 rspec-stories)？当然，我知道两者如何工作并积极使用规范。但用Cucumber还是感觉怪怪的。我目前对此的看法是，当您为客户端实现应用程序并且还不了解整个系统应该如何工作时，使用 Cucumber 很方便。

但是如果我正在做自己的项目怎么办？大多数时候，我知道系统的各个部分如何相互作用。我需要做的就是编写一堆单元测试。那么我需要 Cucumber 时可能出现哪些情况？

并且，作为相应的第二个问题:如果我写 Cucumber 故事，我是否必须编写规范？这不是对同一件事进行双重测试吗？

Answer 1

如果您还没有阅读过，您可能想查看 Dan North 的优秀文章 What's in a Story?作为起点。

Cucumber 故事有两个主要用途。首先，因为故事形式非常具体，所以它有助于产品负责人集中阐述他想要构建的功能。这是故事的“对话 token ”用途，无论我们是否在代码中实现这些故事，这都是有值(value)的。其次，当流程运行得足够好，以至于我们在开始编写功能之前就已经有了完整的故事(更多的是我们为之奋斗的理想，而不是日常现实)，那么您就已经清楚地阐明了您的接受标准并且您确切地知道要构建什么以及构建多少。

在我们的 Rails 工作中，Cucumber 故事不能替代 rspec 单元测试。两者齐头并进。在实践中，单元测试倾向于插入模型和 Controller 的开发，故事倾向于插入 View 的开发(我们倾向于不为我们的 View 编写 rspec)，并从整体上提供对应用程序的良好测试。用户的视角。

如果您单独工作，通信方面可能对您不那么感兴趣，但您从 Cucumber 获得的集成测试可能会感兴趣。如果您利用webrat ，对于许多基本功能来说，编写 Cucumber 可以快速且轻松。