所以我想开始使用RSpec故事，但我不确定编写控制器，模型和视图规范的位置。
例如，你有“登录”故事和“用户提供错误密码”的情况，你最终不会测试与控制器/模型规格相同的东西（response.should render ...，user.should be_nil等。）
所以我的问题是：对于那些习惯用RoR做bdd（或故事dd）的人，你还在写模型/控制器规格吗？如果是这样，您遵循的工作流程如何（“第一个故事，然后缩小到特定规格”）？
答案 0 :(得分：8)
如果您现在开始讲述故事（而不是有很多遗留故事），您可能需要查看Cucumber，这是RSpec故事转轮的长期替代品。
在规范和故事之间进行拆分的最简单方法是使用故事对业务需求进行全栈测试，并针对组件的孤立低级规范（视图，帮助程序，控制器和模型）进行规范。 “完整堆栈”可以是从控制器/模型/数据库到通过Webrat进行客户端仿真到使用Watir或Selenium进行浏览器内测试。
BDD工作方式的最终“外部”是从基于客户要求的故事开始，然后为实现故事时所需的组件添加规范。理想情况下，您将完全覆盖具有规格的各个组件，并为您的用户最重要的工作流程提供故事，以便您可以在最高级别检查您的应用程序是否提供了您所要求的功能。
答案 1 :(得分：3)
我发现故事在测试用户实际执行或观察的行为时非常有用 - 因此，测试响应中包含“登录失败”，而不是测试“失败的登录”模板。恕我直言，如果故事从未直接引用模型，视图或控制器，那就更好了，尽管有时候如果不手动创建模型实例，很难让步骤正常工作。
在我看来，视图，控制器和型号规格只是图片的一部分。他们说实现的语言（“控制器动作X应该做Y模型Z”），并测试你的应用程序的各个部分都做正确的事情。故事通过说出用户的语言来完成图片（“当我发表评论时，我应该看到我发布的评论”）并测试这些部分是否符合客户的验收标准。
我发现一个有用的工作流程是：
这样的故事可以指导您的规格需要测试。
修改：this是一篇很好的文章，涉及故事和规格之间的关系。
答案 2 :(得分：1)
了解他的观点here
答案 3 :(得分：0)
如果您有Cucumber + Capybara，那么跳过视图规范怎么样？我倾向于发现不需要的视图规范。