RSpec vs黄瓜（RSpec故事）

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

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

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

如果还没有，您可能想看看Dan North的出色文章，《故事里有什么？作为起点。

黄瓜的故事有两个主要用途。首先，由于故事形式非常具体，因此有助于使产品所有者明确表达其要构建的功能。这是故事的“对话令牌”，对于无论我们是否在代码中实现故事都非常有价值。其次，当流程运行良好，在开始编写功能之前，我们已经有了完整的故事（比起日常现实，我们更追求的是理想状态），您会清楚地说明接受标准，并且确切地知道什么以及如何做有很多需要建立的。

在我们的Rails工作中，Cucumber故事不能替代rspec单元测试。两者齐头并进。在实践中，单元测试倾向于驱动模型和控制器的开发，而故事则倾向于驱动视图的开发（我们倾向于不为视图编写rspec），并从总体上为整个应用程序提供良好的测试。用户的观点。

如果您是独自工作，则交流方面可能对您而言并不那么有趣，但您可能会从Cucumber获得集成测试。如果您利用webrat的优势，那么对许多基本功能而言，编写Cucumber可以快速而轻松地进行。

将其视为一个周期：

编写您的Cucumber功能，然后在开发该功能的各个部分时，编写规格以完成各个组件。继续完成规格，直到您编写了足够的功能可以使用的功能，然后编写下一个功能。

我认为在大多数情况下使用Cucumber是一个坏主意，因为其语法会给您带来生产力上的成本。我在“ 为什么要打黄瓜测试？”这一主题上写过很多文章。

黄瓜的故事更多地是描述您的应用程序正在解决的整体问题，而不是代码的各个部分是否起作用（即单元测试）。

正如Abie所描述的，它几乎是应用程序应满足的一系列要求，对于与您的客户进行交流以及可直接测试非常有帮助。

如今，您可以将rspec与Capybara和Selenium Webdriver结合使用，而不必构建和维护所有Cucumber故事解析器。这是我的建议：

1. 写出你的故事
2. 使用RSpec，我将创建一个集成测试，例如：spec / integrations / socks_rspec.rb
3. 然后，我将创建一个集成测试，其中包括一个新的描述，它针对每种情况进行阻止
4. 然后，我将实现获得集成测试所需的最小功能，并且在更深入地研究（进入控制器和模型等）时，我将在控制器和模型上进行TDD。
5. 备份后，您的集成测试应该会通过，您可以继续向集成测试添加步骤
6. 重复

但是，需要注意的一件事是，控制器和集成测试可能没有必要重叠，因此您必须根据自己的最佳判断来避免浪费时间。

同样，一旦找到凹槽，您就会发现使用BDD进行开发是最有趣的，直到您不觉得自己做得很完美并且不要过度思考时，才不会感到内gui。你会做的很棒！

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

您仍然需要黄瓜。您需要用它来记录您如何看待系统的工作，还需要用它来确保您在进行更改时没有破坏功能。

换句话说，出于与单元测试相同的原因，您需要Cucumber故事-它们只是在更高的抽象水平上起作用。