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

例如，我们有一个故事"登录"和"用户提供了错误的密码"场景，我们是否最终要测试与控制器/模型规格相同的东西(response.should ...，user.should be_nil等)

所以我的问题是：对于那些习惯使用RoR做bdd(或者故事dd)的人，我们是否仍在编写模型/控制器规范？如果是这样，我们遵循的工作流程如何("第一个故事，然后缩小到特定规格")？

解决方案

如果我们现在开始讲故事(而不是拥有很多旧故事)，则可能需要看一下Cucumber，它可以长期替代RSpec故事执行器。

在规范和故事之间进行拆分的最简单方法是使用故事进行业务需求的全栈测试，并对组件的隔离的低级规范(视图，助手，控制器和模型)使用规范。 "完整堆栈"的范围很广，从控制器/模型/数据库到使用Webrat进行的客户端模拟，再到通过Watir或者Selenium进行的浏览器内测试。

最终的"外部" BDD处理方式是从基于客户需求的故事开始，然后为实现故事时需要的组件添加规格。理想情况下，我们将用规格全面介绍各个组件，并提供有关用户最重要工作流程的故事，以便我们可以从最高级别检查应用程序正在提供所需的功能。

我发现故事在测试用户实际执行或者观察到的行为时很有用，因此与其测试呈现"失败的登录"模板，不如测试响应中包含"无法登录"的故事。恕我直言，最好不要将故事直接引用模型，视图或者控制器，尽管有时不手动创建模型实例就很难使步骤起作用。

正如我所看到的，视图，控制器和模型规格只是图片的一部分。他们说出实现的语言("控制器动作X应该对模型Z做Y")，并测试应用程序的各个部分各自做正确的事情。故事通过说出用户的语言来完成图片("当我发表评论时，我应该看到我发表的评论")，并测试各部分是否符合客户的接受标准。

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

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

这样，故事可以指导我们进行规格测试。

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

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

在这里阅读有关他的观点

如果我们上面有Cucumber + Capybara，该如何跳过视图规格呢？我倾向于发现不需要视图规格。