我目前正在将一些功能测试从Minitest转移到RSpec。我的最后一个问题是访问我在routes.rb中启用的Sidekiq WebUI
require 'sidekiq/web'
require 'admin_constraint'
Rails.application.routes.draw do
mount Sidekiq::Web => '/sidekiq', constraints: AdminConstraint.new
...
endressource是仅受管理员保护的,我现在想要测试它。我有两个问题
1)再次思考这个测试让我思考,它是不是更适合作为路由测试。你认为如何?请记住,它会路由到外部引擎,这可能会使它变得更复杂。特性测试似乎是绕过这一点的一种简单方法(只需测试源码是否可访问)。
2)在Minitest中,我可以执行以下操作,它工作得很好
require_relative '../test_helper'
feature 'Sidekiq dashboard' do
scenario 'Dashboard cannot be reached as guest user' do
assert_raise ActionController::RoutingError do
visit sidekiq_web_path
end
end
scenario 'Dashboard cannot be reached as regular user' do
login_as_user
assert_raise ActionController::RoutingError do
visit sidekiq_web_path
end
end
scenario 'Dashboard can be reached as admin' do
login_as_admin
assert_nothing_raised do
visit sidekiq_web_path
end
end
end我尝试将其直接转换为RSpec,如下所示
scenario 'Dashboard can be reached as user' do
login_as_user
expect {
visit sidekiq_web_path
}.to raise_error(ActionController::RoutingError)
end这会产生以下错误
Failures:
1) Sidekiq dashboard Dashboard cannot be reached as regular user
Got 1 failure and 1 other error:
1.1) Failure/Error:
expect {
visit sidekiq_web_path
}.to raise_error(ActionController::RoutingError)
expected ActionController::RoutingError but nothing was raised
# ./spec/features/sidekiq_monitoring_spec.rb:12:in `block (2 levels) in <top (required)>'
1.2) Failure/Error: raise ActionController::RoutingError, "No route matches [#{env['REQUEST_METHOD']}] #{env['PATH_INFO'].inspect}"
ActionController::RoutingError:
No route matches [GET] "/sidekiq"
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/railties-4.2.7.1/lib/rails/rack/logger.rb:38:in `call_app'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/railties-4.2.7.1/lib/rails/rack/logger.rb:20:in `block in call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/railties-4.2.7.1/lib/rails/rack/logger.rb:20:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/request_store-1.3.2/lib/request_store/middleware.rb:9:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/rack-1.6.5/lib/rack/methodoverride.rb:22:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/rack-1.6.5/lib/rack/runtime.rb:18:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/rack-1.6.5/lib/rack/lock.rb:17:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/rack-1.6.5/lib/rack/sendfile.rb:113:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/railties-4.2.7.1/lib/rails/engine.rb:518:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/railties-4.2.7.1/lib/rails/application.rb:165:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/rack-1.6.5/lib/rack/urlmap.rb:66:in `block in call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/rack-1.6.5/lib/rack/urlmap.rb:50:in `each'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/rack-1.6.5/lib/rack/urlmap.rb:50:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/capybara-2.12.0/lib/capybara/server.rb:43:in `call'
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/rack-1.6.5/lib/rack/handler/webrick.rb:88:in `service'
# ------------------
# --- Caused by: ---
# Capybara::CapybaraError:
# Your application server raised an error - It has been raised in your test code because Capybara.raise_server_errors == true
# /home/blubber/.rvm/gems/ruby-2.3.1/gems/capybara-2.12.0/lib/capybara/session.rb:129:in `raise_server_error!'为什么这在RSpec中不起作用?
提前感谢,祝你一切顺利,安迪
发布于 2017-02-11 03:19:43
当使用支持JS的驱动程序(poltergeist等)进行测试时,Capybara会在单独的服务器线程中运行应用程序。由于应用程序中出现的错误不会自动出现在测试代码中。为了克服这个问题,Capybara存储了在服务器中引发的任何错误,并且由于使用支持JS的驱动程序时命令的异步性质,在下次尝试与Capybara交互时,会在测试代码中重新引发这些错误。因此,您需要在预期引发错误的块中进行第二次交互
expect {
visit sidekiq_web_path
expect(page).to have_text("Something") # the error will actually raise here
}.to raise_error(ActionController::RoutingError)我不知道为什么它会像minitest那样为你工作,我不得不去看看Minitest代码来试图找出原因。如果您使用rack_test驱动程序运行这些测试,我希望您的测试工作正常,因为它不会运行单独的线程,而只是直接调用应用程序(尽管您声称没有更改这一点)。
注意:这确实不是你应该在功能测试中检查的东西,相反,当权限被拒绝/允许时,最好检查页面上显示的内容,而不是引发特定的错误类
https://stackoverflow.com/questions/42158197
复制相似问题