在 rspec 中测试 Sinatra 的重定向
我正在运行 sinatra 应用程序,并使用 rspec 2.7.0 和 webrat 0.7.3(都是最新版本)设置测试套件。我对我的所有请求操作进行了一系列广泛的测试,并且似乎工作正常。今天,我发现了 Sinatra 的 重定向回来 请求级帮助程序,并在以下几个领域实现了它:我的应用程序使用带有参数的 get 请求呈现表单。
redirect back
帮助器的好处是,如果我有一个操作说:
get '/login' do
@used_var = params[:var]
haml :login
end
呈现表单,我可以对接收表单的发布请求进行验证:
post '/login' do
# pretend User.authenticate pulls back a user entry from the database if there
# is a valid username/password combination
unless User.authenticate(params[:username], params[:password]).nil?
redirect '/content'
else
flash[:notice] = "Invalid username/password combo"
redirect back # will redirect back to the get '/login' request
end
end
如果表单未正确验证,它将重定向回带有 from 的页面并保留传入的任何参数,而无需我担心将其存储到会话变量中。唯一的问题是 rspec 似乎不想与 redirect back
帮助器很好地配合。即,如果我有一个执行此操作的规范操作:
it 'should redirect to login when invalid username/password combo is received.' do
get '/login', :var => 'value'
fill_in 'username', :with => 'invalid_username'
fill_in 'password', :with => 'invalid_password'
click_button 'Submit'
last_response.should be_redirect; follow_redirect!
last_request.url.should include("/login")
end
规范无法通过,因为由于某种原因,似乎 rspec
或 webrat
没有在 上识别重定向回
帮助程序,而是将请求重定向回我的应用程序的 root
url ('/'
)。
我想知道是否有办法让 rspec 在这些实例中重定向到正确的位置?当我使用浏览器测试它时,实际的应用程序按预期运行(它将我重定向到带参数的第一页),但 rspec 测试未正确通过。
I am running a sinatra app and have a testing suite setup using rspec 2.7.0
and webrat 0.7.3
(both the most recent versions). I have an extensive set of tests for all of my request actions and it seems to be working fine. Today I discovered Sinatra's redirect back request-level helper and implemented it in a couple of areas of my application that were rendering forms with get requests which were taking parameters.
The nice thing about the redirect back
helper is that if I have an action say:
get '/login' do
@used_var = params[:var]
haml :login
end
Which renders a form, I can have validation on the post request receiving the form:
post '/login' do
# pretend User.authenticate pulls back a user entry from the database if there
# is a valid username/password combination
unless User.authenticate(params[:username], params[:password]).nil?
redirect '/content'
else
flash[:notice] = "Invalid username/password combo"
redirect back # will redirect back to the get '/login' request
end
end
And if the form doesn't validate properly, it will redirect back to the page with the from and retain any parameters that were passed in without me having to worry about storing it to a session variable. The only problem is that rspec doesn't seem to want to play nicely with the redirect back
helper. i.e. if I have a spec action that does this:
it 'should redirect to login when invalid username/password combo is received.' do
get '/login', :var => 'value'
fill_in 'username', :with => 'invalid_username'
fill_in 'password', :with => 'invalid_password'
click_button 'Submit'
last_response.should be_redirect; follow_redirect!
last_request.url.should include("/login")
end
The spec fails to pass because for some reason it seems that rspec
or webrat
isn't picking up on the redirect back
helper and is instead redirecting the request back to the root
url for my application ('/'
).
What I want to know is whether there is a way to get rspec to redirect to the proper location in these instances? The actual application functions as expected when I test it with my browser (it redirects me to the first page with parameters), but the rspec tests don't pass properly.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
尝试传递
:referer =>; '/login'
到您的请求,因此redirect_back
可以知道实际的“返回”在哪里try to pass
:referer => '/login'
to your requests, soredirect_back
can know where the actually 'back' is显然这是 rack 中的一个错误,并且似乎已随着
rack 的发布而得到修复1.3.0。我使用
rack 1.2.5
(1.3.0
发布之前的最新版本)测试了此规范,但失败了,但在升级到1.3
后>,它开始过去了。经过一番挖掘后,非常确定这个拉取请求(这里是提交)是改变修复它。
所以这不再是rack ~> 中的问题。 1.3 。
Apparently this was a bug in rack, and it appears to have been fixed with the release of
rack 1.3.0
. I tested this spec withrack 1.2.5
(most recent version prior to1.3.0
release), and it failed, but upon upgrading to1.3
, it started passing.After some digging around, pretty sure that this pull request (here is the commit) was the change that fixed it.
So it is no longer an issue in
rack ~> 1.3
.