RSpec vs 黄瓜(RSpec 故事)

如果你还没有，你可能想要检查丹诺斯的优秀的文章，故事里有什么？作为一个出发点。

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

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

如果你是独自工作，沟通方面可能对你来说不是那么有趣，但是你从 Cucumber 那里得到的集成测试可能是有趣的。如果你利用 韦伯特，编写黄瓜可以快速和无痛的许多基本功能。

黄瓜故事更多的是描述应用程序正在解决的总体问题，而不是单个代码是否有效(例如单元测试)。

正如 Abie 所描述的，它几乎是应用程序应该满足的需求列表，对于与客户机的通信以及直接可测试都非常有帮助。

把它想象成一个循环:

编写黄瓜特性，然后在开发该特性的各个部分时，编写规范来完成各个组件。继续完成规格说明，直到您编写了足够的功能来通过该特性，然后编写您的下一个特性。

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

你还需要黄瓜。您需要它来记录您如何看待系统工作，并且需要它来确保您在更改事情时没有破坏功能。

换句话说，您需要黄瓜故事的原因和您需要单元测试的原因是一样的——它们只是在更高的抽象层次上工作。

现在，您可以将 rspec 与 Capybara 和 SeleniumWebDriver 一起使用，从而避免构建和维护所有的 Cucumberstory 解析器。以下是我的建议:

1. 写出你的故事
2. 使用 RSpec，我可以创建一个集成测试 ex: spec/Integration/soks _ RSpec. rb
3. 然后，我将创建一个集成测试，其中包括一个新的描述，并为每个场景设置块
4. 然后，我将实现最小的功能需要得到集成测试，同时深入(控制器和模型等) ，我将 TDD 的控制器和模型。
5. 当您返回时，您的集成测试应该会通过，并且您可以继续向集成测试添加步骤
6. 重复

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

此外，一旦你找到了你的最佳状态，你会发现使用 BDD 开发是最有趣的，直到那时，如果你不觉得自己做得很完美，不要过度思考，不要感到内疚。你会做得很好的！

我的看法是，在大多数情况下使用 Cucumber 是一个坏主意，因为它的语法会给您带来生产力方面的成本。我在 为什么要做黄瓜测试呢？上写了很多关于这个话题的文章