9

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

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

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

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

我们断言这两个路由都存在，我们断言它们是 GET 并且它们转到正确的控制器/动作。这有什么意义吗？感觉就像我们现在只是在测试 Rails。

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

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

4

2 回答 2

5

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

这减少了针对广告入口点的回归，无论它们获取或返回的数据如何。

在什么水平上测试这些也是有争议的；测试路线本身是否有价值，还是仅验证数据输入/输出才有意义？这样做也会测试相同的路线，我认为它更有价值——但速度更慢。

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

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

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

于 2013-08-08T03:56:55.063 回答
4

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

例如使用 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
于 2013-08-08T03:17:57.520 回答