RSpec vs黄瓜(RSpec故事)

Question

我应该在什么时候为Rails应用程序使用rspec，什么时候使用Cucumber (以前的rspec-stories)？当然，我知道这两者是如何工作的，并积极使用规范。但使用Cucumber仍然感觉很奇怪。我目前的观点是，当你为客户端实现应用程序时，使用Cucumber是很方便的，因为你还不知道整个系统是如何工作的。

但是如果我在做我自己的项目呢？在大多数情况下，我知道系统的各个部分是如何交互的。我所需要做的就是编写一堆单元测试。当我需要Cucumber的时候，可能的情况是什么？

并且，作为相应的第二个问题:如果我写黄瓜故事，我必须写规范吗？这不是同样的事情的双重测试吗？

Answer 1

如果你还没有，你可能想看看Dan North的一篇很棒的文章，What's in a Story?作为一个起点。

我们有两个关于黄瓜故事的主要用途。首先，因为故事形式非常具体，它有助于集中产品所有者对他想要构建的功能的表达。这是对故事的“会话令牌”的使用，无论我们是否在代码中实现故事，它都是有价值的。其次，当这个过程运行得足够好，我们在开始编写特性之前已经有了完整的故事(比起日常的现实，我们更多的是为了理想而努力)，你就有了清晰的验收标准，你确切地知道要构建什么和构建多少。

在我们的Rails工作中，Cucumber故事不能替代rspec单元测试。两者齐头并进。在实践中，单元测试倾向于驱动模型和控制器的开发，而故事倾向于驱动视图的开发(我们倾向于不为我们的视图编写rspec )，并从用户的角度对整个应用程序进行良好的测试。

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

Answer 2

把它想象成一个循环：

编写您的Cucumber特性，然后在为该特性开发组件时，编写规范以完成各个组件。继续完成规范，直到您编写了足够的功能以通过该功能，然后编写您的下一个功能。

Answer 3

我的观点是，在大多数情况下使用Cucumber是一个坏主意，因为它的语法会给您带来生产力方面的成本。我用Why Bother With Cucumber Tests?写了很多关于这个主题的文章。