所以我想开始使用RSpec的故事,但我不知道编写控制器,模型和视图规范的位置.
例如,您的故事“登录”与“用户提供错误的密码”场景,不要最终测试与控制器/模型规格相同的东西(response.should render …,user.should be_nil等) .)
所以我的问题是：对于那些习惯于用roR做bdd(或者故事的)的人,你还会写模型/控制器的规格吗？如果是,您遵循的工作流程(“第一个故事,然后缩小到具体规格”)？
如果你现在开始讲故事(而不是有很多遗产故事),你可能想看看
Cucumber这是RSpec故事赛跑者的长期替代品.
在规范和故事之间分割的最简单的方法是使用故事进行业务需求的全栈测试,以及组件(视图,帮助器,控制器和模型)的隔离低级规范的规范. “完全堆栈”可以从控制器/模型/数据库到使用Webrat进行客户端仿真到Watir或Selenium进行浏览器测试.
最终的“外在”BDD的做事方式是从基于客户要求的故事开始,然后在实施故事时添加您需要的组件的规格.理想情况下,您将完全覆盖具有规格的各个组件,并为用户最重要的工作流程提供故事,以便您可以在最高级别检查您的应用程序提供的功能.
