ruby-on-rails - RSpec 故事和规格：何时使用什么？

Question

所以我想开始使用 RSpec 故事，但我不确定在哪里编写控制器、模型和视图规范。

例如，您有“登录”和“用户提供错误密码”场景的故事，您最终不会测试与控制器/模型规范相同的东西（response.should render...，user.should be_nil 等.)

所以我的问题是：对于那些习惯用 RoR 做 bdd（或故事 dd）的人，你还写模型/控制器规范吗？如果是这样，您遵循的工作流程如何（“第一个故事，然后缩小到特定规格”）？

Answer 1

如果您现在从故事开始（而不是有很多遗留故事），您可能想看看Cucumber，它是 RSpec 故事运行器的长期替代品。

在规范和故事之间进行拆分的最简单方法是使用故事进行业务需求的全栈测试，并使用规范对组件（视图、帮助程序、控制器和模型）的隔离低级规范进行测试。“全栈”的范围可以从控制器/模型/数据库到使用 Webrat 的客户端模拟，再到使用 Watir 或 Selenium 进行的浏览器内测试。

BDD 的最终“外在”做事方式是从基于客户需求的故事开始，然后为您在实施故事时发现需要的组件添加规范。理想情况下，您将使用规范完全覆盖各个组件，并为用户最重要的工作流程提供故事，以便您可以在最高级别检查您的应用程序是否提供了您所要求的功能。

Answer 2

我发现故事在测试用户实际执行或观察到的行为时很有用 - 因此，与其测试“登录失败”模板是否呈现，不如测试响应是否包含“登录失败”。恕我直言，如果故事从不直接引用模型、视图或控制器会更好，尽管有时如果不手动创建模型实例就很难让这些步骤正常工作。

在我看来，视图、控制器和模型规格只是图片的一部分。他们讲实现的语言（“控制器操作 X 应该对模型 Z 做 Y”），并测试你的应用程序的各个部分是否都做正确的事情。故事通过说出用户的语言（“当我发表评论时，我应该看到我发表的评论”）并测试部件以符合客户接受标准的方式组合在一起来完成图片。

我发现一个有用的工作流程是：

• 写一个故事场景来描述我需要添加的功能。
• 尽快为该故事编写步骤，以便您可以运行它（即使所有步骤都失败了）。
• 为那个故事需要的东西写一个规范（模型可能是一个很好的起点）。
• 编写代码以使该规范通过。
• 编写更多规范和代码，直到故事结束。

这样，故事就可以指导您了解您的规格需要测试的内容。

编辑：这是一篇很好的文章，涉及故事和规格之间的关系。

Answer 3

Pat Maddox（RSpec 核心团队）认为，在某些假设下，您可以在使用 Cucumber 故事/功能时跳过控制器规范

在这里阅读他的观点

Answer 4

如果你有 Cucumber+Capybara，那么跳过视图规范怎么样。我倾向于找到不需要的视图规范。