我刚开始学 RSpec 写测试，我发现 spec 目录下有好多目录，我从网上找资料发现， 从 Rails 5 和 RSpec 3.5 开始，不建议做 controller 的测试，而是做 feature 和 request 的测试
- controllers
- features
- helpers
- mailers
- models
- requests
- routing
这几个当中，我是不是可以不写 controllers，还有 features（用 Capybara 做）可以覆盖 requests 和 routing，所以这俩（requests，routing）是不是可以不做？
hz_qiuyuanxin
回复
我是写过的，只是觉得这几个 controllers，requests，routing，features 好像做重复的事情，是不是其中几个是不需要做的
fan124
回复
我最近有写 request 测试，就是请求一个 api，就会到控制器，所以就包括 mvc，route 了。feature 不知道是什么。
chenge
回复
features 我是写了用 Capybara 的集成测试，我在想 requests 是不是完全代替 controllers，但是不用 assigns 和 assert_template，http://rspec.info/blog/2016/07/rspec-3-5-has-been-released/ 这儿的 Rails: Support for Rails 5 提到 request spec
msl12
回复
好像是不建议用 assigns 和 assert_template，但是如果 controller 里有逻辑需要测时，还是可以测，我对测试还是新手，你也可以参考这个 https://gitlab.com/gitlab-org/gitlab-ce/issues/23768
Rei
回复
如果有（可能）比 Default Stack 更好的选择，为什么不用更好的呢？
而且 Default Stack 本身也一直在改变，比如 WebServer 之前用 Webrick 现在改用 Puma 了。
fan124
回复
我个人倾向于把业务逻辑拆分到app/service和app/lib下，然后分开做模块的单元测试。主程序基本只考虑做request or feature测试，这样相对来说比较容易维护测试代码，因为细节的实现可能会经常改动，但是只要对外的行为不变就没问题。
msg7086
回复
如果 default stack 不够用了，再找替代品。但我看过很多人换 Rspec 之前甚至没写过 Unit::Test。
Default Stack 的变更会提供平滑迁移方案，自己替换的会延迟、疼痛或没有方案。
如果你的 controller 返回的是 html，那确实不应该测试，因为 html 和最终用户看到的并不一致，而且 js 交互也需要 acceptance 测试。
Rspec 会鼓励写深层嵌套、抽象、魔幻的代码，简单事情复杂化，增加学习成本和维护难度。增加一个 Gem 不只是加几行代码，而是在应用中引入了一个理念，和原有理念融合或冲突，升级框架的时候成为依赖阻碍。
我希望有一天某个应用积重难返时，不要怪 Ruby 太魔幻、Rails 太重，然后希望在新语言新框架重新开始。代码是自己写的，这是自己选择的结果。
msg7086
回复
已有项目就没办法了，遵循团队约定是最合适的。
Rails 5.1 出来写个人项目的时候可以试试 Default Stack，恰好这次更新对测试有改动。