RSpec故事和规格：何时使用哪个？

Question

我想开始使用RSpec故事，但我不确定编写控制器、模型和视图规范的位置。

例如，您有“登录”故事，其中包含“用户提供错误密码”的情况，你最终不是在测试与控制器/模型规范相同的内容（response.should render...、user.should be_nil等）吗？

所以我的问题是：对于那些习惯于使用RoR进行BDD(或Story DD)的人，是否仍然编写模型/控制器规范？如果是这样，你遵循什么工作流程（“首先是故事，然后缩小到具体规范”）？

- Luciano

Answer 1

如果您现在开始使用故事（而不是有很多遗留故事），您可能想看看Cucumber，这是RSpec story runner的长期替代品。

将规范和故事区分开来的最简单方法是使用故事对业务需求进行全栈测试，使用规范对组件（视图、辅助器、控制器和模型）进行隔离的低级别规范。'Full stack'可以从控制器/模型/数据库到使用Webrat进行客户端模拟，再到使用Watir或Selenium进行浏览器内测试的范围。

最终的'BDD外部'处理方式是从客户要求开始编写故事，然后在实现故事时添加所需的组件规范。理想情况下，您将完全涵盖各个组件的规范，并为用户最重要的工作流程编写故事，以便在最高层次上检查您的应用程序是否提供了您被要求提供的功能。

- domgblackwell

Answer 2

我发现，故事测试用户实际执行或观察的行为非常有用——因此，与其测试“失败的登录”模板是否被渲染，不如测试响应是否包含“登录失败”。在我看来，最好的情况是，故事从未直接涉及模型、视图或控制器，尽管有时很难在没有手动创建模型实例的情况下让步骤正常运行。

就我而言，视图、控制器和模型规范只是这个过程的一部分。它们使用实现语言（“控制器操作X应对模型Z进行Y操作”）并测试应用程序的各个部分是否都做正确的事情。故事通过使用用户语言（“当我发布评论时，应该看到我发布的评论”）以及测试各部分是否以符合客户验收标准的方式组合起来，来完成整张图。

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

- 编写描述需要添加功能的故事场景。 - 尽早编写故事的步骤，以便您可以运行它（即使所有步骤都失败）。 - 为该故事所需的某些内容编写规范（模型可能是个好地方）。 - 编写代码以使该规范符合要求。 - 编写更多规范和代码，直至故事通过。

那样故事就能指导您的规格需要测试什么。 编辑: this 是一篇很好的文章，涉及到故事和规格之间的关系。

- Sam Stokes

Answer 3

Pat Maddox（RSpec核心团队成员）认为，在某些假设下，当使用Cucumber故事/特性时，可以跳过控制器规范。

在这里阅读他的观点。

- Daniel Cadenas

Answer 4

如果你已经使用了Cucumber+Capybara，那么跳过视图规范怎么样？我倾向于认为视图规范是不必要的。

- mech