测试 rails generate integration_test 目录 request 还是 feature
在使用了 rspec 和 capybara 后 rails generate integration_test 如何能生成的目录放在 feature 下， 好像默认还是放在 request 下 可否修改
feature specs 不是单纯的 integration test，不建议这么改；RSpec 和 Capybara 联手引入 feature specs 不是为了取代 request specs，别误会了这一点，建议读一下 RSpec Rails Documentation
#3 楼 @golden05 我不知道，应该是没有，要想有也不是不可以，不过要去修改 rails 的 generator 吧？
我觉得没必要有一个专门的命令，因为 feature specs 经常会跨越多个 view 或 model 所 handle 的 范围，它不是框架的一个部分，而是对整个应用的某个“方面”的测试。
request specs 虽然也类似，但它毕竟是 rails 内置的 integration test 的 wrapper，rails 本身就有 integration test 的机制，所以 generator 提供了创建目录和文件的功能也实属正常。
feature specs 针对的是应用外在的表现、行为以及结果，它相当于 user test 或者 acceptance test。以前这个层面的测试通常都会用 Cucumber 或类似的工具来完成，capybara 原本是 cucumber 的绝配（用来模拟用户在 UI 上的交互操作，并帮助返回期望的测试结果），可是 rails 的开发者们更偏爱灵活强大的 RSpec，于是逐渐演变成了使用 request specs 来代替验收测试的部分功能。
这样做其实是不妥的，request specs 应当正对某种应用场景的内部处理过程进行测试，在其内部测试用例调用的都应该是 rails 的内置方法或专门为 integration test 提供的 helpers，capybara 的频繁介入是因为开发者想要通过操作或监视外部（UI）的表现来验证内部的处理机制。久而久之，request specs 已经远远偏离了它存在的初始意义，而相应的 integration test 变得越来越不纯粹。
正是由于这个原因，当 capybara 进行到 2.0 的时候，和 RSpec 的开发团队做出了共同的决定，为 RSpec 增加新的 feature level specs，并且把 capybara 的使用限定在 feature specs 里，还特别为 feature specs 创建了很多 DSL alias，比如 background => before, given => let, scenario => it, feature => describe 等，这么做的目的就是为了给开发者提供一个更加纯粹的验收测试语境，从而让偏爱 RSpec 的开发者有足够好的工具来取代 Cucumber。
我正在录制一期关于 RSpec 的教学视频，针对初学者的，一开始就特别讲述了上述的一些概念，等我制作好了会分享给大家，希望大家对于 RSpec Capybara 有更全面和深入的了解。
@zhulinpinyu @blueplanet @Vincent178 ok，ok，大家的热情我都了解了，我现在正在整理 Rails 4 的变化，等这个写完了就把视频弄完，因为我想在视频里都用 Rails 4 的代码，已经开始录了，再等等。
