在Rails路由中测试什么？
我很好奇人们认为对路线进行充分/彻底的测试。 我工作的人似乎想要在我们的路线文件中断言每条路线，无论标准如何。 我觉得这是浪费时间，但也许我错了，我不知道这有什么价值。
在某些情况下，我可以在路由中看到一些价值。 我们仍然有一些响应GET和POST请求的动作，尽管我一直想要摆脱它们。 我们没有任何关于lambdas或任何东西的疯狂约束，但是如果我们这样做，那似乎值得测试。
但是对于正常的资源定义？
resources :foo, only: [:index, :show] 我们断言这两条路线都存在，我们声称它们是GET并且它们会转到正确的控制器/动作。 这有什么意义吗？ 感觉就像我们刚刚测试Rails一样。
在一个稍微相关的问题上，我更喜欢定义像上面那样的资源路径（ only: [:index, :show]部分）。 仅定义resources :foo是否有任何后果resources :foo如果该控制器上只有索引/显示操作，则路径文件中为resources :foo ？
在我看来，它可能只是使用更多的时间和/或内存，但它是否也是一个安全问题，或者是我不知道的非常糟糕的东西？
测试路由的最大原因不是对Rails进行双重测试，而是要validation面向公众的API。
这减少了广告入口点的回归，无论它们采取或返回的数据如何。
对这些问题进行测试的程度也可以进行一些辩论; 测试路线本身是否有价值，或者仅validation进/出的数据是否有意义？ 这样做也测试相同的路线，我认为更有价值 – 但速度较慢。
我倾向于只在以下情况下直接测试路线：
- 它们有点时髦，例如，不是沼泽标准的路线
- 我必须拒绝一些路线
- 在初步开发期间。
初步路线测试一旦以其他方式进行测试，通常会被删除。
我测试路由以确保我想要允许的路由是开放的，但也要我想要关闭的路由不起作用。 我将路由规范分为三个上下文 – 允许的路由，不允许的路由和自定义路由。
例如使用rspec
describe SessionsController do describe "routing" do context "permitted" do it "routes to #create" do expect(post "sessions").to route_to("sessions#create") end ... end context "custom routes" do it "routes 'login' to #new" do expect(get "/login").to route_to("sessions#new") end ... end context "invalid routes" do it "does not route to #edit" do expect(get "/sessions/edit").not_to be_routable end ... end end end