所以我想开始使用 RSpec 故事，但我不确定在哪里编写控制器、模型和视图规范。
例如，您有故事“登录”和“用户提供错误密码”场景，您最终不会测试与控制器/模型规格相同的东西（response.should render...，user.should be_nil 等）
所以我的问题是：对于那些习惯于使用 RoR 进行 bdd（或故事 dd）的人，您还编写模型/控制器规范吗？如果是这样，您遵循的工作流程如何（“第一个故事，然后缩小到特定规范”）？
【问题讨论】：
标签： ruby-on-rails ruby rspec bdd rspec-stories
如果你有 Cucumber+Capybara，那么跳过视图规范怎么样。我倾向于找到不需要的视图规范。
【讨论】：
Pat Maddox（RSpec 核心团队）认为，在某些假设下，您可以在使用 Cucumber 故事/功能时跳过控制器规范
阅读他的观点here
【讨论】：
我发现故事在测试用户实际执行或观察到的行为时很有用 - 因此，与其测试“登录失败”模板是否呈现，不如测试响应是否包含“登录失败”。恕我直言，故事从不直接引用模型、视图或控制器会更好，尽管有时如果不手动创建模型实例就很难让这些步骤正常工作。
在我看来，视图、控制器和模型规格只是图片的一部分。他们讲实现的语言（“控制器动作 X 应该对模型 Z 做 Y”），并测试你的应用程序的各个部分是否都做正确的事情。故事通过说出用户的语言（“当我发表评论时，我应该看到我发表的评论”）并测试各部分是否以符合客户接受标准的方式组合在一起来完成图片。
我发现一个有用的工作流程是：
这样，故事就可以指导您了解需要测试的规格。
编辑：this 是一篇很好的文章，涉及到故事和规格之间的关系。
【讨论】：
如果您现在从故事开始（而不是有很多遗留故事），您可能需要查看 Cucumber，它是 RSpec 故事运行器的长期替代品。
拆分规范和故事的最简单方法是使用故事对业务需求进行全栈测试，并使用规范对组件（视图、帮助程序、控制器和模型）的隔离低级规范进行测试。 “全栈”的范围可以从控制器/模型/数据库到使用 Webrat 进行客户端模拟，再到使用 Watir 或 Selenium 进行浏览器内测试。
最终的“由外而内”的 BDD 做事方式是从基于客户需求的故事开始，然后为您在实施故事时发现需要的组件添加规范。理想情况下，您将使用规范全面涵盖各个组件，并为用户最重要的工作流程提供故事，以便您可以在最高级别检查您的应用是否提供了您所要求的功能。
【讨论】：