RSpec与黄瓜（RSpec故事）

Question

我什么时候应该使用Rails应用程序的规格和黄瓜（前rspec故事）？当然，我知道如何工作和积极使用规范。但使用黄瓜仍然感觉很奇怪。我目前对此的看法是，当您为客户端实现应用程序并且不了解整个系统应该如何工作时，使用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?

中广泛撰写了这个主题

Answer 4

Cucumber故事更多地描述了您的应用程序正在解决的整体问题，而不是单个代码位的工作（即单元测试）。

正如Abie所描述的那样，它几乎是应用程序应满足的要求列表，对与客户的沟通非常有帮助，并且可以直接测试。

Answer 5

现在你可以在Capybara和Selenium Webdriver中使用rspec，避免构建和维护所有的Cucumber故事解析器。以下是我的建议：

1. 写出你的故事
2. 使用RSpec，我会创建一个集成测试ex：spec / integrations / socks_rspec.rb
3. 然后我会创建一个集成测试，其中包含一个新的描述和每个场景的阻止
4. 然后我会实现最低功能要求以进行集成测试，同时深入了解（进入控制器和模型等）我会在控制器和模型上进行TDD。
5. 当您回来时，您的集成测试应该通过，您可以继续添加集成测试的步骤
6. 重复

然而，有一点需要注意的是，控制器和集成测试可能没有必要重叠，因此您必须使用最佳判断，这样您就不会浪费时间。

此外，一旦你找到了你的凹槽，你会发现使用BDD进行开发是最愉快的，直到那时如果你不觉得你做得很完美并且不要过度思考就不要感到愧疚。你会做得很棒！

Answer 6

  

但是，如果我正在做自己的项目呢？在大多数情况下，我知道系统的各个部分是如何相互作用的。我需要做的就是写一堆单元测试。那时我需要黄瓜的可能情况是什么？

你还需要黄瓜。你需要它来记录你看到系统如何工作，你需要它来确保你在改变时没有破坏功能。

换句话说，您需要Cucumber故事的原因与您需要进行单元测试的原因相同 - 它们只是在更高层次的抽象上工作。