Question

我很好奇人们认为对路线进行充分/彻底的测试。我工作的人似乎想在路由文件中断言每个路由，无论标准如何。我觉得这是浪费时间，但也许我错了，我不知道这有什么价值。

在某些情况下，我可以在路由中看到一些价值。我们仍然有一些响应GET和POST请求的动作，虽然我一直想要摆脱它们。我们没有任何关于lambdas或任何东西的疯狂约束，但如果我们这样做，那似乎值得测试。

但是对于正常的资源定义？

resources :foo, only: [:index, :show]

我们断言这两条路线都存在，我们声称它们是GET并且它们会转到正确的控制器/动作。这有什么意义吗？感觉就像我们刚刚测试Rails一样。

在一个稍微相关的问题上，我更喜欢定义如上所述的资源路线（only: [:index, :show]部分）。如果在该控制器上只有索引/显示操作，那么仅在路由文件中定义resources :foo会有什么后果吗？

在我看来，它可能只是在使用更多的时间和/或内存，但它是否也是一种安全问题或者我不知道的非常糟糕的事情？

Answer 1

测试路由的最大原因不是对Rails进行双重测试，而是要验证面向公众的API。

这可以减少广告入口点的回归，无论它们采取或返回的数据如何。

用于测试这些内容的级别也可以进行一些辩论;测试路线本身是否有价值，或者仅验证进/出的数据是否有意义？这样做也测试相同的路线，我认为更有价值 - 但速度较慢。

我倾向于只在以下情况下直接测试路线：

它们有点时髦，例如，不是沼泽标准路线
我必须拒绝一些路线
初步开发期间。

初步路线测试一旦以其他方式进行测试，通常会被删除。

Answer 2

我测试路由以确保我想要允许的路由是开放的，但也要我想要关闭的路由不起作用。我将路由规范分为三个上下文 - 允许的路由，不允许的路由和自定义路由。

e.g。使用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

在Rails路由中测试什么？

2 个答案: