[Wtr-development] automatic waiting?
charley.baker at gmail.com
Tue Oct 19 23:35:48 EDT 2010
This was part of what I did in Taza in creating hooks for (aribitrary
procs, usually but not always, wait methods for elements) using a
basic Page model. It's worked well for 10's of thousands of tests on
Ajax heavy sites - Gap brands, Facebook, and others. If Taza doesn't
work for you then you may be doing something wrong. :) There are
multiple points at which we can decide to handle timeouts and element
failures, whether Watir itself needs to deal with it or not is also
I'll pull consesus and we need to summarize what we want to do for the
watir api. I'm not in favor of including this in the base api, and
don't like any of the addon api methods. Sorry, I'm tired after a long
weekend. :) Will spend some time on the webdriver api as well to match
Lead Developer, Watir, http://watir.com
On Tue, Oct 19, 2010 at 7:06 PM, Bret Pettichord <bret at pettichord.com> wrote:
> On Tue, Oct 19, 2010 at 3:03 PM, Jarmo <jarmo.p at gmail.com> wrote:
>> Jari, Charley, Bret and anyone else, what are your thoughts on the
>> subject (it would be better if you answered only if you've used Watir
>> something similar).
> I would like to see a proposal, first, for a new method that encapsulates
> your entire proposal. I'm seeing lots of interesting ideas and interesting
> objections and counter-proposals, so I'm still unclear if there is a crisp
> idea in your mind of what you want to do.
> This actually sounds like a good use case for Google Wave; too bad it died.
> To me, the core scenario is
> browser.element(:attribute, 'value').when_present.click (or set or
> By making this a new method, it allows us to focus on exactly how we would
> configure the when_present method (how long to wait, wait for visible?
> exists? both, other methods, too?). Like i said i would like a clear
> proposal on this. Because in itself this raises no issues of compatibility,
> it will be easier to reach consensus on what this needs to be to be most
> To me you are struggling over the corner cases because you are jumping to
> step 2, which would be for Watir to always make calls to when_present. And
> do me there is a real question about whether you would always do this or
> perhaps only for some/most methods. Also it raises the issue about whether
> this level of "implicit" invokation would itself need to be configurable.
> The third step would be to talk about deprecation and forcing people to use
> this new scheme. To me it is premature to discuss such matters. Typically it
> takes us years after new methods are introduced before we can discuss
> deprecation and even then there are often many people who stick to the old
> I also liked Jari's comments about how much of this might simply be avoided
> with proper use of page objects. Personally I always use page objects, but I
> don't think this technique is understood by the majority of the Watir
> community. Maybe we just need some better writing, explanation in this area.
> Or maybe someone should create a page object class/library/gem that itself
> includes the automatic waiting functionality that you are proposing. It
> might make sense to bundle that with some of the new rspec matchers that
> have been discussed here as well.
> Bret Pettichord
> Lead Developer, Watir, www.watir.com
> Blog, www.io.com/~wazmo/blog
> Twitter, www.twitter.com/bpettichord
> Wtr-development mailing list
> Wtr-development at rubyforge.org
More information about the Wtr-development