在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