我什么时候应该为 Rails 应用程序使用规范，什么时候应该使用 Cucumber（以前的 rspec-stories）？当然，我知道规范的工作方式和积极使用规范的方式。但是使用 Cucumber 仍然感觉很奇怪。我目前对此的看法是，当您为客户端实现应用程序并且还不了解整个系统应该如何工作时，使用 Cucumber 很方便。
但是如果我在做自己的项目呢？大多数时候，我知道系统的各个部分是如何交互的。我需要做的就是编写一堆单元测试。那么我需要 Cucumber 的可能情况是什么？
并且，作为相应的第二个问题：如果我写 Cucumber 故事，我是否必须写规范？这不是对同一件事进行双重测试吗？
如果您还没有，您可能想查看 Dan North 的优秀文章，故事中有什么？作为起点。
Cucumber 故事有两个主要用途。首先，因为故事形式非常具体，它有助于集中产品所有者对他想要构建的功能的阐述。这是故事的“对话令牌”使用，无论我们是否在代码中实现故事都是有价值的。其次，如果流程运行良好，以至于我们在开始编写功能之前就有了完整的故事（更多的是我们为之奋斗的理想，而不是日常现实），那么您就可以清楚地说明您的验收标准，并且您确切地知道什么以及如何很多东西要建造。
在我们的 Rails 工作中，Cucumber 故事不能替代 rspec 单元测试。两者齐头并进。在实践中，单元测试倾向于推动模型和控制器的开发，而故事倾向于推动视图的开发（我们倾向于不为我们的视图编写 rspec）并从整体上提供对应用程序的良好测试用户的视角。
如果您是单独工作，通信方面可能对您来说不是那么有趣，但您从 Cucumber 获得的集成测试可能会很有趣。如果您利用webrat，对于您的许多基本功能，编写 Cucumber 可以快速而轻松。
把它想象成一个循环：
编写您的 Cucumber 功能，然后在开发该功能的部分时，编写规范以完成各个组件。继续完成规范，直到您编写了足够的功能以使该功能通过，然后再编写您的下一个功能。
我的看法是，在大多数情况下使用 Cucumber 是个坏主意，因为它的语法会给您带来生产力成本。我在为什么要打扰黄瓜测试？
Cucumber 故事更多的是描述您的应用程序正在解决的整体问题，而不是单个代码位是否有效（即单元测试）。
正如 Abie 所描述的，它几乎是应用程序应满足的要求的列表，并且对于与您的客户沟通以及可直接测试非常有帮助。
现在，您可以将 rspec 与 Capybara 和 Selenium Webdriver 一起使用，而不必构建和维护所有 Cucumber 故事解析器。以下是我的建议：
然而，需要注意的一件事是控制器和集成测试有重叠，这可能不是必需的，因此您必须使用最佳判断，以免浪费时间。
此外，一旦您找到了自己的最佳状态，您会发现使用 BDD 进行开发是最令人愉快的，在此之前，如果您觉得自己做得不够完美并且不要过度思考，请不要感到内疚。你会做得很好！
但是如果我在做自己的项目呢？大多数时候，我知道系统的各个部分是如何交互的。我需要做的就是编写一堆单元测试。那么我需要 Cucumber 的可能情况是什么？
你仍然需要黄瓜。您需要它来记录您如何看待系统工作，并且您需要它来确保您在更改内容时没有破坏功能。
换句话说，您需要 Cucumber 故事的原因与您需要单元测试的原因相同——它们只是在更高级别的抽象上工作。