测试 feature spec / integration spec ( request spec) / controller spec 的区别
如题。
最近写测试的时候开始有点晕，不知道feature spec / integration spec / controller spec都应该测试什么
比如说，有这样一个场景
已登陆的用户，可以新建帖子
那我的开发过程是这样的
- 新建一个
feature spec文件，使用capybara来模拟上述内容 ``` feature '已登录的用户，可以新建帖子' do include_context '用户登录' before { visit new_topic_path }
scenario '选择社区，填写标题和正文后，点击保存，可以新建一个帖子' do expect { select 'Testing', from: 'topic_node' fill_in 'topic_title', with: '测试' fill_in 'topic_content', with: '测试正文' click_button '保存' }.to change(Topic, :count).by(1) end end
* 然后执行测试，根据失败提示来继续开发
* 我原本是只写`feature`的测试来保证覆盖率的，有高手说，`feature`只测试功能，应该用`unit spec'来保证测试覆盖率
* OK。那我把原来写在`feature`里面的各种验证的测试都改成`unit spec`，也就是`controller spec`, `model spec`，`feature spec`里面只保留基本的正常流程的`spec`。
### 到这里为止我还都理解。但之后就有点糊涂了。如果这样的话，那`request spec` 里面应该写哪些测试呢？
个人看法不一定正确：
Feature Test 是测试一个完整的功能的，而且是偏向于从用户交互的角度来描述。往往是从用户的输入开始，到反馈给用户的输出结束，隐藏中间的，特别是系统内部的处理过程。
按照我个人的习惯，楼主给出的例子我觉得就不是太合适，输入是好的，因为操作的目标都是 UI 的元素，但是输出却是系统内部的，实际上用户并不知道也不会关心 change(Topic, :count).by(1) 这一步。
更恰当的测试应该是检查 UI 上能够反映出计数加 1 的地方，比如说某处显示的帖子总数之类的。我感觉 Feature Test 比较接近于常说的验收测试，这从 RSpec 和 Capybara 在前一段进行重构当中可以明显体现出来（Capybara 不再推荐用于除 Feature Test 以外的测试）
Request Test 则是去除了和 UI 相关的部分，测试的目的是为了覆盖从用户发起请求到系统响应结果的全过程（单一功能的），这期间会包含 controller 的部分是很正常的，但是粒度不必很细，而且也会包含其他的部分，比如 routes，有的时候还会涉及外部服务
Controller Test 就是测试只和 controller 内部处理逻辑相关的单元测试，往往不一定是按照具体的功能划分测试的范围，而是按照方法的调用次序或彼此之间的依赖关系。
如果把各种测试平行来看的话，真的会觉得不好区分，所以个人看法是重点理解不同测试所关注的层级不同，因此测试时的范围、代入上下文，操作对象、期望值等等也就各有不同。从开发者的角度来看，很多测试可能说的是一会儿事，但却是从不同角度或不同粒度来进行的描述，所以如果你觉得重复了，要么尝试从不同的角度来看待你要测试的东西，要么暂且放下，等有了核实的“视角”之后再来。
单纯追求测试覆盖率指标是没有太大必要的，对于设计和实现良好的应用程序来说，测试能覆盖比较关键或比较复杂容易出错的业务逻辑就可以了，毕竟测试不是万能的，有的时候问题往往出现在非代码层面，比如说业务分析错了，或者系统设计得不够好，这个时候你的测试覆盖率再高也无济于事。从这个角度来看，假如你无法从个角度和层级来描述清楚你要测试的东西，那很可能你需要倒退回设计阶段仔细考虑清楚自己有没有把这个“东西”想清楚了。
#1 楼 @nightire 非常感谢！ 茅塞顿开的感觉！！
我的疑惑都解决了。而且明确了我思路中最基本的一个错误。
我在潜意识中认为各个测试应该是互相不重复的，这在根本上就错了。这里讨论的各个spec，实际上是不同角色从不同角度进行的测试。所以从结果来看的话，可能大多数情况下都会有重复的部分，只是如你所说，
……因此测试时的范围、代入上下文，操作对象、期望值等等也就各有不同……
最后对于测试覆盖率的指正也非常感谢。这个问题我最近也慢慢意识到了。测试覆盖率确实是能反映一定的问题，并不是覆盖 100% 了就怎么怎么了。如你所说的业务分析错误或者开发者和客户沟通中的理解错误等都无法体现
我的视角确实一直局限在了开发者。以后需要从多个角度考虑！
再次感谢！