Open patrick99e99 opened 9 years ago
Also having this issue! Exactly the same - Completed 302 Found, and then a GET for the next page. Capybara somehow executing the expectations on the next page.
Hi @patrick99e99, I was trying to update my gem versions and perhaps I'm running your same problem.
I have a visit
to user destroy session and then a expectation about the content of the page.
But it returns a blank page like
<html><head></head><body></body></html>
I have tracked the version of capybara-webkit that this error first appears.
I have
and ...
@patrick99e99, could you try capybara-webkit 1.5.2 on your setup to see if the issue is only from 1.6.0. I think this could be of value to someone trying to fix it.
And also, I have changed this in my setup. (As you said that a cached GET is the suspect, I think should be important to show these fragments also).
config/routes.rb
MyAppName::Application.routes.draw do
devise_for :users, :controllers => { :sessions => "users/sessions" }
# It seems devise always send GET requests.
# The destroy session would be a DELETE request.
# Making GET possible for production sessions#destroy seems
# to be a security failure.
# So we make a GET route available _only_ on tests.
if Rails.env.test?
devise_scope :user do
get '/users/sign_out' => 'devise/sessions#destroy'
end
end
# ...
end
config/initializers/devise.rb
Devise.setup do |config|
#...
# The default HTTP method used to sign out a resource. Default is :delete.
config.sign_out_via = :delete
config.sign_out_via = :get if Rails.env.test?
# ...
end
@abinoam I think the change in 1.6 related to what you're seeing is https://github.com/thoughtbot/capybara-webkit/pull/775.
It seems very likely that this is because QtWebKit is caching something between test runs. We have some ongoing discussion about that on https://github.com/thoughtbot/capybara-webkit/issues/724.
@patrick99e99 Since you are using Rails, in your config/environments/test.rb
add:
Rails.application.configure do
#... all your other stuffs
config.middleware.delete Rack::ETag
end
You'll see in your test debug output that you are getting a 304 and things fall apart from there. We were getting the same issue and 304 was causing capybara to give us a response body exactly as you posted above.
I have the simplest of simple as far as tests go:
... This fails, claiming it was unable to find the selector 'form'. This is an intermittent failure (my favorite kind) which happens every few spec runs. I found that if I use the seed of a failing test run, it will fail each and every time which means somehow it has something to do with previous browser state. I am assuming that for some reason, capybara-webkit sometimes gets hung up on 302 redirects, as the sign out link goes to /sign_out and that redirects to /sign_in. Since I can reproduce this with the same random seed, I was able to do screenshot prior to failure and I see: http://tinyurl.com/pm3tlfm
It is a blank page... Nothing there.. I tried setting my default max timeout is set to something ridiculous like 30 seconds... It never shows anything. However, my rails test log shows during this failing spec:
So it is rendering the page.. Capybara is somehow just not getting the response.
.... Also since I can reproduce this with the seed, I spent over an hour debugging / troubleshooting by going in and commenting out previous specs to isolate what about the current test order causes this failure. I finally found there is one spec, if I comment it out, this sign out spec no longer fails... And guess what that spec is doing? Clicking cancel on a modal which signs out the user. So I am suspecting the action of visiting /sign_out is somehow getting cached in capybara-webkit, and the second time it gets that it just goes to that "blank page" without actually redirecting
This is what my capybara-webkit debug shows during the failure: