是否仍然建议使用 Minitest 在 Rails 4 中测试路线？答案

【问题标题】：Is it still advisable to test routes in Rails 4 with Minitest?是否仍然建议使用 Minitest 在 Rails 4 中测试路线？
【发布时间】：2014-09-16 05:01:09
【问题描述】：

在 Rails 3 中，在 MiniTest 中编写功能测试时，我养成了将路由测试与控制器操作分开测试的习惯。我从Rails Guide on Testing - Section 9: Testing Routes 得到了这个想法。但是，在将我的应用程序升级到 Rails 4 后，我注意到如果我没有为 get|patch|post|delete 方法提供一组适当的参数，控制器操作测试本身已经开始对未知路由犹豫不决。

例如，给定路线：

# config/routes.rb
namespace "api" do
  namespace "v2", defaults: { format: :json } do
    resources :users do
      resources :posts do
        resources :comments
      end
    end
  end
end

及功能测试：

# test/controllers/api/v2/comments_controller_test.rb
describe Api::V2::CommentsController
  it "does something" do
    get :index
  end
end

在 Rails 3 中，上述方法可以工作。但在 Rails 4 中，我得到一个 URL 生成错误：

ActionController::UrlGenerationError: 没有路由匹配 {:action=>"index", :controller=>"api/v2/cmets"}

由此我可以推断，get 助手在尝试定位控制器和操作时根本无法匹配路由文件中的路由。很公平。我可以通过更改 get 调用以包含满足嵌套路由所需的参数来解决此问题，如下所示：

# test/controllers/api/v2/comments_controller_test.rb
describe Api::V2::CommentsController
  it "does something" do
    get :index, { user_id: "1", post_id: "1" }
  end
end

...然后一切都好起来了。

所以我的问题是，既然在 Rails 3 中不是这种情况，现在可以信任控制器操作测试来完全测试/验证我在 Rails 4+ 中的路由吗？或者在测试路线方面还有其他优势吗？路线测试是否涵盖了控制器操作测试未涵盖的其他角度？（注意：我并不是要对什么是好的测试提出意见；我是在询问路由集成测试和控制器操作测试在路由要求方面的功能差异。）

另外，我在 Rails 4 发行说明（或 Minitest）中找不到对这种行为变化的具体参考，所以我想知道为什么首先做出这种行为变化。我不认为这是一件坏事——我认为这很好——但我觉得在某个地方的变更日志中没有提到它很奇怪。而且我认为get|patch|post|delete 方法的一半目的是让您不必首先考虑路由所需的参数。

为了完整起见，这是我将用于此的路线测试：

describe "CommentsController Route Integration Test" do
  let(:default_options) {
    { controller: "api/v2/comments",
      user_id: "1",
      posts_id: "1",
      format: :json }
  }

  it "#index" do
    assert_routing "/api/v2/users/1/posts/1/comments",
                   default_options.merge(action: "index")
  end
end

更新

我一直在通过 ActionDispatch 代码寻找答案...到目前为止，我唯一能看到的是 url_for 自 Rails 3 以来发生了很大变化，并且 ActionController::UrlGenerationError 类本身已经在 Rails 4 中添加。因此，这些新的、更严格的路由要求可能是对 ActionView 和 ActionController 解耦的偶然更改。

【问题讨论】：

标签： ruby-on-rails ruby ruby-on-rails-4 minitest

【解决方案1】：

我相信测试路由和控制器是完全没有必要的，因为您已经进行了功能测试。这并不能直接回答您的问题，但应该可以解决您的困境。我建议阅读各种测试哲学，并（进一步）就如何测试和测试什么形成一个理想的观点。

【讨论】：

谢谢。我一直在关注 TDD 死了吗？我个人倾向于同意其中的大部分内容。但是你不能测试 API 端点，这就是我最近在做的很多事情。
发送请求并检查响应有什么问题？
感谢您提出这一点...我会记住的。也就是说，虽然我能理解你的观点，但我对编写和依赖功能测试并不像我对编写和依赖功能测试那样舒服。我用于功能测试的 Web 驱动程序似乎对测试套件的速度产生了深远的影响，而功能测试实际上非常快，无论我可能需要设置什么来测试实际的前端功能。此外，我仍然喜欢我可以将我的控制器与他们的“视图”分开测试（我在我的 API 操作中使用演示者作为我的视图）。

【解决方案2】：

在最近为几个新控制器编写了功能测试之后，没有编写任何路由集成测试，我相当确信测试路由的额外工作是多余的。给定，即是否有覆盖所有路由的功能测试。

我的推理基本上是......在任何情况下，我向控制器操作中的get|patch|post|delete 调用提供了不正确的参数，它总是失败。每当我为存在但缺少相应路由的控制器操作编写测试时，它总是会失败。因此，似乎更高级别的功能测试也可以很好地执行较低级别的路由集成测试——所以为什么还要重复努力！

我想我将来仍然会寻找更新的“官方”字眼，但现在我决定不再担心在存在重叠功能测试时直接测试我的路线。

更新

我进一步决定测试 API 路由可能仍然有用。这有助于确保使用 API 发布的实际 URL string 实际上是正确且有效的。请注意，测试字符串而不是命名路由很重要，因为命名路由会随着路由文件中资源的更改而改变。

【讨论】：