所以我想开始使用 RSpec 故事，但我不确定编写控制器、模型和视图规范适合在哪里。
例如，您有故事“登录”和“用户提供了错误的密码”场景，您不结束吗测试与控制器/模型规格相同的内容（response.should render...、user.should be_nil 等）
所以我的问题是：对于那些习惯于使用 RoR 执行 bdd（或 Story dd）的人，你会吗？还在写型号/控制器规格吗？ 如果是这样，您遵循的工作流程如何（“第一个故事，然后缩小到特定规格”）？
So I want to start using RSpec stories, but I am not sure where writing controller, model and view specs fit in.
For example, you have the story "Logging in" with "User provides wrong password" scenario, don't you end up testing the same stuff than controller/model specs (response.should render..., user.should be_nil, etc.)
So my question is: for those who are used to doing bdd (or story dd) with RoR, do you still write model/controller specs? If so, how is the workflow you follow ("first story, then narrow to specific specs")?
发布评论
评论（4）
如果您现在从故事开始（而不是有很多遗留故事），您可能需要查看 Cucumber 是 RSpec 故事运行器的长期替代品。
划分规范和故事的最简单方法是使用故事进行业务需求的全栈测试，并使用规范来隔离组件的低级规范（视图、帮助器、控制器和模型）。 “全栈”的范围可以从控制器/模型/数据库到使用 Webrat 的客户端模拟，再到使用 Watir 或 Selenium 的浏览器内测试。
最终的“由外而内”BDD 做事方式是从基于客户需求的故事开始，然后在实现故事时添加您发现需要的组件的规格。 理想情况下，您将完全涵盖各个组件的规格，并为用户最重要的工作流程提供故事，以便您可以在最高级别检查您的应用程序是否提供了您所要求的功能。
If you are starting with stories now (as opposed to having a lot of legacy stories) you may want to look at Cucumber which is the long term replacement for the RSpec story runner.
The easiest way of splitting between specs and stories is to use stories for full-stack testing of business requirements and specs for isolated low-level specifications of the components (views, helpers, controllers and models). 'Full stack' can a range from controller/model/database through client simulation with Webrat to in-browser testing with Watir or Selenium.
The ultimate 'outside in' BDD way of doing things is to start with stories based on customer requirements and then add in specs for the components you find you need when implementing the stories. Ideally you will fully cover the individual components with specs and have stories for the most important workflows of your users so you can check at the highest level that your app is delivering the functionality you have been asked for.
我发现故事在测试用户实际执行或观察到的行为时非常有用 - 因此，与其测试是否呈现“登录失败”模板，不如测试响应是否包含“登录失败”。 恕我直言，如果故事从不直接引用模型、视图或控制器，那就更好了，尽管有时在不手动创建模型实例的情况下很难让这些步骤正常工作。
在我看来，视图、控制器和模型规格只是图片的一部分。 他们使用实现语言（“控制器操作 X 应该对模型 Z 执行 Y 操作”），并测试应用程序的各个部分是否都执行正确的操作。 故事通过说出用户的语言（“当我发布评论时，我应该看到我发布的评论”）并测试各部分是否以符合客户接受标准的方式组合在一起来完成图片。
我发现一个有用的工作流程是：
这样，故事就可以指导您了解需要测试的规格。
编辑：这是一篇很好的文章，涉及故事和规范之间的关系。
I find stories are useful when they test the behaviour the user actually performs or observes - so rather than testing that the "failed login" template is rendered, test that the response contains "failed to log in". IMHO it's better if stories never refer to models, views or controllers directly, although sometimes it's hard to get the steps working without creating model instances manually.
As I see it, view, controller and model specs are only part of the picture. They speak the language of implementation ("controller action X should do Y to model Z"), and test that the individual parts of your app each do the right thing. Stories complete the picture by speaking the language of the user ("when I post a comment I should see the comment I posted") and testing that the parts fit together in a way that meets the customer's acceptance criteria.
I find a useful workflow is:
That way the story can guide you in what your specs need to test.
Edit: this is a good article which touches on the relationship between stories and specs.
Pat Maddox（RSpec 核心团队）认为，在某些假设下，您可以在使用 Cucumber 故事/功能时跳过控制器规格
阅读他的观点 此处
Pat Maddox (RSpec core team) thinks that under some assumptions, you can skip controller specs when using Cucumber stories/features
Read about his point of view here
如果你有 Cucumber+Capybara，那么跳过视图规范怎么样？ 我倾向于发现不需要视图规范。
What about skipping view spec if you've got Cucumber+Capybara on it. I tend to find view spec not needed.