RSpec故事和规格:何时使用什么？

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

例如,你有"登录"故事与"用户提供错误密码"的情况,你不是最终测试相同的东西而不是控制器/模型规格(response.should渲染...,user.should be_nil等.)

所以我的问题是:对于那些习惯用RoR做bdd(或故事dd)的人,你还在写模型/控制器规格吗？如果是这样,您遵循的工作流程如何("第一个故事,然后缩小到特定规格")？

如果你现在开始讲故事(而不是有很多遗留故事),你可能想看看Cucumber,它是RSpec故事跑者的长期替代品.

在规范和故事之间进行拆分的最简单方法是使用故事进行业务需求的全栈测试,以及组件的孤立低级规范(视图,帮助器,控制器和模型)的规范."完整堆栈"可以从控制器/模型/数据库到通过Webrat的客户端模拟到使用Watir或Selenium的浏览器内测试.

最终的"外部"BDD工作方式是从基于客户要求的故事开始,然后为实现故事时所需的组件添加规范.理想情况下,您将完全覆盖具有规格的各个组件,并为您的用户最重要的工作流程提供故事,以便您可以在最高级别检查您的应用程序是否提供了您所要求的功能.