Message from discussion
How do I reliably determine that a change event has executed?
Received: by 10.58.2.40 with SMTP id 8mr5838109ver.14.1344483410504;
Wed, 08 Aug 2012 20:36:50 -0700 (PDT)
X-BeenThere: ruby-capybara@googlegroups.com
Received: by 10.52.69.174 with SMTP id f14ls1898432vdu.2.gmail; Wed, 08 Aug
2012 20:36:49 -0700 (PDT)
Received: by 10.52.174.167 with SMTP id bt7mr2471527vdc.15.1344483409315;
Wed, 08 Aug 2012 20:36:49 -0700 (PDT)
Date: Wed, 8 Aug 2012 20:36:47 -0700 (PDT)
From: "M. Scott Ford" <sc...@goulet-ford.com>
To: ruby-capybara@googlegroups.com
Message-Id: <c416f4da-07eb-46b7-a820-c757252aa150@googlegroups.com>
In-Reply-To: <CAJP-NHvUm8aV3+XWB-LUVbzbAxpbZn=ZecL9xSZ886byG+YLrQ@mail.gmail.com>
References: <ed62bfc3-7d32-4ab7-b8b8-f360982b60d8@googlegroups.com>
<CAJP-NHsT9NWQfo7m83oR+eiOzWtedErweLsZwhAriv6O0wcskQ@mail.gmail.com>
<34ec4a71-20b5-4d1f-a89f-07aff457cf29@googlegroups.com> <CAJP-NHtNrbSZ_+VMe-rLMOkK2GuNMzerJmmLnFp8q_rWnTOuCA@mail.gmail.com>
<fb3232f1-d506-4694-9412-bbf25b40bd83@googlegroups.com>
<CAJP-NHvUm8aV3+XWB-LUVbzbAxpbZn=ZecL9xSZ886byG+YLrQ@mail.gmail.com>
Subject: Re: [Capybara] How do I reliably determine that a change event has
executed?
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_153_198896.1344483407649"
------=_Part_153_198896.1344483407649
Content-Type: multipart/alternative;
boundary="----=_Part_154_20972849.1344483407649"
------=_Part_154_20972849.1344483407649
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Hi Jonas,
I took the time to reproduce the issue using a little code as possible.
I've posted it to a gist[1]. Should I create a Github issue for this?
[1]: https://gist.github.com/3300676
Thanks,
-Scott
On Wednesday, August 8, 2012 3:48:22 PM UTC-4, jnicklas wrote:
>
> There shouldn't be any difference between 1.1.X and 2.0 in that
> regard. It should wait for the content to disappear off the page.
> Check the README section on AJAX if you're unsure of how this works.
>
> /Jonas
>
> On Wed, Aug 8, 2012 at 9:39 PM, M. Scott Ford <sc...@goulet-ford.com<javascript:>>
> wrote:
> > Does `page.should_not` trigger the same retry behavior that
> `page.should`
> > does? It looks to me like that might be the difference between 1.1.2 and
> > 2.0.0.beta2.
> >
> >
> > On Wednesday, August 8, 2012 3:36:29 PM UTC-4, jnicklas wrote:
> >>
> >> I can't tell you why that is failing, the error is too generic. You'll
> >> have to investigate further!
> >>
> >> /Jonas
> >>
> >> On Wed, Aug 8, 2012 at 8:57 PM, M. Scott Ford <sc...@goulet-ford.com>
> >> wrote:
> >> > Jonas,
> >> >
> >> > Thanks for the guidance.
> >> >
> >> > Based on your suggestions, I have simplified the approach. The test
> now
> >> > looks like this.
> >> >
> >> >
> >> > find('#presenter_outreach_transaction_groups_morethan_true').click
> >> > fill_in 'transactions.', :with => '6'
> >> > find('label', :text => 'People who have performed').click
> >> >
> >> > page.should_not have_content('Loading')
> >> > find('#total_users .txt').should have_content('1')
> >> >
> >> > This passes every time when run against capybara 2.0.0.beta2, but
> fails
> >> > every time when run against capybara 1.1.2. Here's the failure that
> I'm
> >> > getting.
> >> >
> >> > Failure/Error: page.should_not have_content('Loading')
> >> > expected content "Loading" not to return anything
> >> >
> >> > I'm not sure our project is ready to make the switch to 2.0.0.beta2,
> >> > yet.
> >> > Thoughts?
> >> >
> >> > On Tuesday, August 7, 2012 1:00:39 PM UTC-4, jnicklas wrote:
> >> >>
> >> >> Capybara is very good at waiting for content. Replace this:
> >> >>
> >> >> all('label', :text => 'more').first.click
> >> >>
> >> >> With this:
> >> >>
> >> >> find('label', :text => 'more').click
> >> >>
> >> >> Remove all the manual waiting. Should do the trick.
> >> >>
> >> >> /Jonas
> >> >>
> >> >> On Tue, Aug 7, 2012 at 6:18 PM, M. Scott Ford <sc...@goulet-ford.com>
>
> >> >> wrote:
> >> >> > Hello all,
> >> >> >
> >> >> > I'm hoping someone can help point me in the direction of the best
> way
> >> >> > to
> >> >> > solve a problem that I encountered.
> >> >> >
> >> >> > I've written a series of tests for a page that performs an AJAX
> >> >> > request
> >> >> > when any of several form elements is changed. During the AJAX
> call, a
> >> >> > model
> >> >> > loading box is displayed.
> >> >> >
> >> >> > My tests sometimes succeed. Sometimes they fail. Which tests fail
> >> >> > seems
> >> >> > to be be non-deterministic. Sometimes only one of them fails.
> >> >> > Sometimes it's
> >> >> > all of them.
> >> >> >
> >> >> > When the test does fail, it seems to be because the final AJAX
> event
> >> >> > is
> >> >> > not triggered. I'm not sure what could cause this. I tried adding
> >> >> > code to
> >> >> > look for the presence of the loading modal. While that improved
> >> >> > things a
> >> >> > little (all of the tests pass a higher percentage of the time), I
> >> >> > still get
> >> >> > inconsistent failures.
> >> >> >
> >> >> > Here's an example of one of the tests. I've included the
> >> >> > `wait_for_loading` method to show what I've tried. That method is
> a
> >> >> > recent
> >> >> > addition. It's probably named poorly. A better name might be
> >> >> > `wait_for_loading_box_to_be_invisible`.
> >> >> >
> >> >> > def wait_for_loading
> >> >> > begin
> >> >> > wait_until { !find('#loading', :visible => false).visible?
> }
> >> >> > rescue Capybara::TimeoutError
> >> >> > flunk 'Expected loading modal to be hidden'
> >> >> > end
> >> >> > end
> >> >> >
> >> >> > describe 'adjusting only number of transactions' do
> >> >> > it 'should show the correct number of users with more than 6
> >> >> > transactions' do
> >> >> > all('label', :text => 'more').first.click
> >> >> > wait_for_loading
> >> >> > fill_in 'transactions.', :with => '6'
> >> >> > wait_for_loading
> >> >> > find('label', :text => 'People who have performed').click
> >> >> > wait_for_loading
> >> >> >
> >> >> > # before the test runs this value will be 4
> >> >> > find('#total_users .txt').should have_content('1')
> >> >> > end
> >> >> > end
> >> >> >
> >> >> > In case it's relevant to the discussion. Here's the version of
> both
> >> >> > capybara and selenium-webdriver that are reported by Gemfile.lock.
> >> >> >
> >> >> > version numbers:
> >> >> > capybara = 1.1.2
> >> >> > selenium-webdriver = 2.22.1
> >> >> >
> >> >> > I'd appreciate any guidance towards a better way to write this
> test.
> >> >> >
> >> >> > Thanks,
> >> >> > -Scott
>
------=_Part_154_20972849.1344483407649
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi Jonas,<div><br></div><div>I took the time to reproduce the issue using a little code as possible. I've posted it to a gist[1]. Should I create a Github issue for this?</div><div><br></div><div>[1]: https://gist.github.com/3300676</div><div><br></div><div>Thanks,</div><div>-Scott<br><br>On Wednesday, August 8, 2012 3:48:22 PM UTC-4, jnicklas wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">There shouldn't be any difference between 1.1.X and 2.0 in that
<br>regard. It should wait for the content to disappear off the page.
<br>Check the README section on AJAX if you're unsure of how this works.
<br>
<br>/Jonas
<br>
<br>On Wed, Aug 8, 2012 at 9:39 PM, M. Scott Ford <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="u8cKRTVVPMIJ">sc...@goulet-ford.com</a>> wrote:
<br>> Does `page.should_not` trigger the same retry behavior that `page.should`
<br>> does? It looks to me like that might be the difference between 1.1.2 and
<br>> 2.0.0.beta2.
<br>>
<br>>
<br>> On Wednesday, August 8, 2012 3:36:29 PM UTC-4, jnicklas wrote:
<br>>>
<br>>> I can't tell you why that is failing, the error is too generic. You'll
<br>>> have to investigate further!
<br>>>
<br>>> /Jonas
<br>>>
<br>>> On Wed, Aug 8, 2012 at 8:57 PM, M. Scott Ford <<a>sc...@goulet-ford.com</a>>
<br>>> wrote:
<br>>> > Jonas,
<br>>> >
<br>>> > Thanks for the guidance.
<br>>> >
<br>>> > Based on your suggestions, I have simplified the approach. The test now
<br>>> > looks like this.
<br>>> >
<br>>> >
<br>>> > find('#presenter_outreach_<wbr>transaction_groups_morethan_<wbr>true').click
<br>>> > fill_in 'transactions.', :with => '6'
<br>>> > find('label', :text => 'People who have performed').click
<br>>> >
<br>>> > page.should_not have_content('Loading')
<br>>> > find('#total_users .txt').should have_content('1')
<br>>> >
<br>>> > This passes every time when run against capybara 2.0.0.beta2, but fails
<br>>> > every time when run against capybara 1.1.2. Here's the failure that I'm
<br>>> > getting.
<br>>> >
<br>>> > Failure/Error: page.should_not have_content('Loading')
<br>>> > expected content "Loading" not to return anything
<br>>> >
<br>>> > I'm not sure our project is ready to make the switch to 2.0.0.beta2,
<br>>> > yet.
<br>>> > Thoughts?
<br>>> >
<br>>> > On Tuesday, August 7, 2012 1:00:39 PM UTC-4, jnicklas wrote:
<br>>> >>
<br>>> >> Capybara is very good at waiting for content. Replace this:
<br>>> >>
<br>>> >> all('label', :text => 'more').first.click
<br>>> >>
<br>>> >> With this:
<br>>> >>
<br>>> >> find('label', :text => 'more').click
<br>>> >>
<br>>> >> Remove all the manual waiting. Should do the trick.
<br>>> >>
<br>>> >> /Jonas
<br>>> >>
<br>>> >> On Tue, Aug 7, 2012 at 6:18 PM, M. Scott Ford <<a>sc...@goulet-ford.com</a>>
<br>>> >> wrote:
<br>>> >> > Hello all,
<br>>> >> >
<br>>> >> > I'm hoping someone can help point me in the direction of the best way
<br>>> >> > to
<br>>> >> > solve a problem that I encountered.
<br>>> >> >
<br>>> >> > I've written a series of tests for a page that performs an AJAX
<br>>> >> > request
<br>>> >> > when any of several form elements is changed. During the AJAX call, a
<br>>> >> > model
<br>>> >> > loading box is displayed.
<br>>> >> >
<br>>> >> > My tests sometimes succeed. Sometimes they fail. Which tests fail
<br>>> >> > seems
<br>>> >> > to be be non-deterministic. Sometimes only one of them fails.
<br>>> >> > Sometimes it's
<br>>> >> > all of them.
<br>>> >> >
<br>>> >> > When the test does fail, it seems to be because the final AJAX event
<br>>> >> > is
<br>>> >> > not triggered. I'm not sure what could cause this. I tried adding
<br>>> >> > code to
<br>>> >> > look for the presence of the loading modal. While that improved
<br>>> >> > things a
<br>>> >> > little (all of the tests pass a higher percentage of the time), I
<br>>> >> > still get
<br>>> >> > inconsistent failures.
<br>>> >> >
<br>>> >> > Here's an example of one of the tests. I've included the
<br>>> >> > `wait_for_loading` method to show what I've tried. That method is a
<br>>> >> > recent
<br>>> >> > addition. It's probably named poorly. A better name might be
<br>>> >> > `wait_for_loading_box_to_be_<wbr>invisible`.
<br>>> >> >
<br>>> >> > def wait_for_loading
<br>>> >> > begin
<br>>> >> > wait_until { !find('#loading', :visible => false).visible? }
<br>>> >> > rescue Capybara::TimeoutError
<br>>> >> > flunk 'Expected loading modal to be hidden'
<br>>> >> > end
<br>>> >> > end
<br>>> >> >
<br>>> >> > describe 'adjusting only number of transactions' do
<br>>> >> > it 'should show the correct number of users with more than 6
<br>>> >> > transactions' do
<br>>> >> > all('label', :text => 'more').first.click
<br>>> >> > wait_for_loading
<br>>> >> > fill_in 'transactions.', :with => '6'
<br>>> >> > wait_for_loading
<br>>> >> > find('label', :text => 'People who have performed').click
<br>>> >> > wait_for_loading
<br>>> >> >
<br>>> >> > # before the test runs this value will be 4
<br>>> >> > find('#total_users .txt').should have_content('1')
<br>>> >> > end
<br>>> >> > end
<br>>> >> >
<br>>> >> > In case it's relevant to the discussion. Here's the version of both
<br>>> >> > capybara and selenium-webdriver that are reported by Gemfile.lock.
<br>>> >> >
<br>>> >> > version numbers:
<br>>> >> > capybara = 1.1.2
<br>>> >> > selenium-webdriver = 2.22.1
<br>>> >> >
<br>>> >> > I'd appreciate any guidance towards a better way to write this test.
<br>>> >> >
<br>>> >> > Thanks,
<br>>> >> > -Scott
<br></blockquote></div>
------=_Part_154_20972849.1344483407649--
------=_Part_153_198896.1344483407649--