Hanging in click_button?
Eric Hahn
it "should be able to sign me up as us...@example.com" do
visit register_url
fill_in "user[email]", :with => "us...@example.com"
click_button # hangs here indefinitely until rspec timeout...
end
And here's what's in the test.log (after rake spec:integration)
Processing UsersController#new (for 127.0.0.1 at 2009-11-17 16:25:09) [GET]
Parameters: {"action"=>"new", "controller"=>"users"}
Rendering template within layouts/application
Rendering users/new
Rendered layouts/_nav (9.0ms)
Completed in 8802ms (View: 2617, DB: 1) | 200 OK [http://www.example.com/register]
REQUESTING PAGE: POST /users with {"user"=>{"email"=>"us...@example.com"}, "commit"=>"Register!", "authenticity_token"=>"CC5/G9hGENY817VeTce5Be2Xh8vrhNxog8N/h7ekZT4="} and HTTP headers {"HTTP_REFERER"=>"http://www.example.com/register"}
... then silence!
My UsersController never sees UsersController#create! I think webrat is hanging inside its process_request method but args there looked good (checked via breakpoint).
Ruby 1.8.6 patchlevel 111, Rails 2.3.4
Webrat 0.5.3, nokogiri 1.4.0
Any ideas on where I should be looking? Thanks for any pointers whatsoever!
ehahn
* The SECOND web request, whatever it is, seems to hang indefinitely
(and timeout per rspec).
For example:
it "should visit the home page" do
visit home_path
visit home_path
end
The second visit never returns! I wonder if somehow it is trying to
access www.example.com (the default HTTP_HOST value in tests), but
that wouldn't explain why the first visit works fine.
I'm sort of stuck with webrat on this blocker, so anything suggestions
would be hugely appreciated.
BTW, my Webrat.mode => :rails and this is running under Windows.
Matt Wynne
On 20 Nov 2009, at 17:04, ehahn wrote:
>
> Update: looks like the problem isn't quite as I described. Rather:
>
> * The SECOND web request, whatever it is, seems to hang indefinitely
> (and timeout per rspec).
>
> For example:
>
> it "should visit the home page" do
> visit home_path
> visit home_path
> end
>
> The second visit never returns! I wonder if somehow it is trying to
> access www.example.com (the default HTTP_HOST value in tests), but
> that wouldn't explain why the first visit works fine.
>
> I'm sort of stuck with webrat on this blocker, so anything suggestions
> would be hugely appreciated.
>
> BTW, my Webrat.mode => :rails and this is running under Windows.
(probably log/test.log) to see if you can figure out where the call is
getting stuck. Also you could try stepping through the second request
with ruby-debug but you will probably see some scary stuff down there
if this is your first integration test!
Matt
+447974 430184
ma...@mattwynne.net
http://mattwynne.net
Larry Siden
Larry Siden
http://umich.edu/~lsiden
734-926-9614
skype: lsiden
ehahn
I have indeed done more digging and I think I have something of a
smoking gun.
Turns out the patch given in this thread
https://rails.lighthouseapp.com/projects/8994/tickets/3153-actioncontrollerintegrationsession-broken-in-234
fixes my problem exactly:
Around line 310 of actionpack/lib/action_controller/integration.rb
app = Rack::Lint.new(@application)
status, headers, body = app.call(env)
+ body.close if body.respond_to?(:close)
+
@request_count += 1
@html_document = nil
So now the obvious question is why does my app need this patch when
other, simpler ones don't! I'm not 100% I understand what
ActionController::Integration::Session is doing with the added
body.close(), but I'm wondering if it points to my app not correctly
responding (bad HTML? incorrect/missing respond_to? not sure)?
My next plan is to dramatically cut down the complexity of this
particular response (for example: returning trivial HTML content from
the template instead of the "real" content, etc.). But anyone with
other suggestions would be a hero!
Thanks.
On Nov 22, 4:10 pm, Larry Siden <lsi...@gmail.com> wrote:
> Oops, forgot again to mention that this is Webrat::Mechanize. No Rails! :)
>
> 734-926-9614
> skype: lsiden
> On Sun, Nov 22, 2009 at 1:52 PM, Matt Wynne <m...@mattwynne.net> wrote:
>
> > On 20 Nov 2009, at 17:04, ehahn wrote:
>
> > > Update: looks like the problem isn't quite as I described. Rather:
>
> > > * The SECOND web request, whatever it is, seems to hang indefinitely
> > > (and timeout per rspec).
>
> > > For example:
>
> > > it "should visit the home page" do
> > > visit home_path
> > > visit home_path
> > > end
>
> > > The second visit never returns! I wonder if somehow it is trying to
> >http://mattwynne.net