To rule out some basic issues, I'd first set the wait timeout to about
1 second for DOM lookups (can't remember the setting right now), and
then prepending almost every step that checks for an element with
'wait_until { has_css?(css) }'.
That will ensure your tests fail quickly if it's just cucumber getting
confused by ajax.On Oct 8, 8:13 am, Alex Cooper <[email protected]> wrote: > Hi Mikel, > > many thanks for the excellent reply. Yep, I'm talking about deadlock > happening somewhere in the interpreter/cucmber/selenium stack. I can fairly > confidently rule out this being a database thing, having done some more > poking around since Bo's suggestion last night. (I mean "deadlock" as in > philosophers dining, not as in the common SQL database exception message. > <grin>) > > I'll give your fix a try. Perhaps the key would be to modify my step > definitions to always check a call has returned. > > When you say AJAX call, do you mean AJAX on the actual application's page, or > is this something to do with the WebDriver interface? We aren't > (deliberately) making any AJAX calls in our app. > > I'm not sure if this is related, but we have also had very strange things > happening with capybara, where it becomes really, really slow (as in, 1 step > every 2 minutes or so). Again, causes seem non-deterministic--and it's really > degrading the quality of our test suite. > > I've been treating capybara as a bit of a black box, and I have to confess I > really don't know anything about its internals. Is there any way to make > browser calls block until they've been executed by the browser, so this can't > happen? > > Muchas gracias, > > - alex. > > On 08/10/2010, at 2:57 AM, Mikel Lindsaar wrote: > > > > > > > > > > > Hi Alex, > > > What is the deadlock, are you talking about an exception being thrown by > > the DB deadlocking? > > > If you are talking about a cucumber / selenium "deadlock" as in it just > > sits there waiting for something to appear, this can happen when the test > > suite is moving too fast for updates to happen... > > > For example: > > > Given I am on the home page > > ( this site adds a "login" link once the remote user IP Address is > > checked first) > > And I follow "login" > > Then I should be on my dashboard. > > > This will fail if the ajax call does not get the login link to appear > > before the test tries to follow the login link. > > > A way to solve this is add an explicit expectation before the follow: > > > Given I am on the home page > > Then I should see "login" > > When I follow "login" > > Then I should be on my dashboard. > > > This way, the system waits for the login link to appear before trying to > > follow it. > > > Mikel > > > On 08/10/2010, at 12:32 AM, Alex Cooper wrote: > > >> Hi everybody, > > >> I uncovered a rather unnerving race condition at work (GetUp) today, and > >> I'd love to know if anyone else has seen this. > > >> I've been getting a erratic, but reproducible lockups under ruby 1.9.2 and > >> cucumber/capybara [1]. But under ruby 1.8.7 it's fine. > > >> This sucks, because we'd really like to use 1.9.2 for its much improved > >> performance. > > >> The cucumber script does nothing special. Populate the DB, fill in some > >> fields, press a button or two. Sometimes cucumber hangs midway through the > >> test--but at different locations. This behavior is seen on other features, > >> too, but it's mainly in the same few scenarios. > > >> Steps to reproduce: > >> rvm use 1.8.7 > >> bundle exec cucumber features/example.feature [2] > >> observe soothing green output > >> rvm use 1.9.2 > >> bundle exec cucumber features/example.feature > >> tear hair out when deadlock occurs [3] > > >> The kicker is that it happens in different places in the cucumber script, > >> and there's no predictable pattern I can discern as to exactly which step > >> (or type of step) will hang. > > >> I suspect deadlock, because output halts midway through a scenario, CPU > >> drops to zero, memory usage remains stable, and Ruby no longer responds to > >> SIGINT (which I think it normally would). > > >> So, my questions for the floor are, in increasing order of importance: > >> Has anyone on the list experienced (and hopefully fixed) this problem? > >> How would you approach tracking this bad boy down? (Preferably not > >> involving MRI source code and gdb.) > >> Which particular alcoholic beverage is preferred for drowning one's > >> sorrows while debugging bugs like this? > > >> Cheers, and many thanks in advance, > > >> - alex. > > >> Notes: > >> The environment is: Rails 3.0, Ruby 1.9.2, cucumber 0.9.0, cucumber-rails > >> 0.3.2, webrick 1.3.1, postgres 8.4.4, OSX Snow Leopard > >> There really is nothing special about this script--it just fills in inputs > >> and pushes buttons. > >> On different machines, deadlock occurs with different frequency. On my > >> (slow) MBP with 2G memory, it happens about 70% of the time. On a > >> colleague's older (but faster) machine, it locks up around 30% of the time. > > >> -- > >> Alex Cooper m: 0402 024 304 w:http://acooper.org/ > >> t: @kuperov > > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "Ruby or Rails Oceania" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]. > >> For more options, visit this group > >> athttp://groups.google.com/group/rails-oceania?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby or Rails Oceania" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/rails-oceania?hl=en. > > -- > Alex Cooper m: 0402 024 304 w:http://acooper.org/ t: > @kuperov -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
