[Wtr-development] automatic waiting?

brett sykes brettcsykes at gmail.com
Tue Oct 19 16:39:55 EDT 2010

This seems like a really good idea. What I'm currently doing with our AJAX
heavy site now feels very overcomplicated.

On Tue, Oct 19, 2010 at 4:03 PM, Jarmo <jarmo.p at gmail.com> wrote:

> On Tue, Oct 19, 2010 at 9:26 PM, Ethan <notethan at gmail.com> wrote:
> > It seems like it would be very confusing that a method #not_exists? would
> > behave differently than !#exists? (or even need to be defined). I would
> > avoid it. This goes back to what I was saying that I think this should
> > happen in #initialize rather than in subsequent existence-checking.
> The only thing that would behave differently would be the automatic
> waiting. Otherwise it would behave the same so i don't see much of a
> problem. Agreed though that it would make the API more complicated and
> possibly confusing. I still don't see any advantages of waiting
> automatically in #initialize due to the fact as you itself mentioned
> later on that you're checking also non-existance of an elements.
> > Implementing waiting versions of any given commonly-used method (and its
> > negation, to boot) sounds like it would confuse the API a lot. Given that
> > you can use any of those to specify locating a div, checking whether a
> > div(:text, some_text).exists? seems preferable to checking
> > div.has_text?(some_text)
> You just gave actually a great idea - instead of using wait_until
> {div.text == "something"} you could use wait_until {div(:text =>
> "something").exists?}. This means that #exists? could in theory wait.
> I haven't used :text locator in these circumstances at all. This means
> also that the only possible automatically waiting methods could be
> #exists? and #visible? ...
> > However, another idea is extending rspec with a waiting version of its
> > checker. Implement an extension 'should_eventually' (or whatever name,
> > that's just off the top of my head), such that:
> >   div.should_eventually exist
> > will run a waiter checking div's existence, and fail if it doesn't come
> into
> > existence within whatever timeout. You could use this with checking text
> or
> > classname or whatever without implementing waiting versions of those
> > methods.
> > I don't know where an extension like that should live, exactly, it seems
> > outside the scope of watir itself. but, it's an idea.
> Yup, i also thought about that, but this means that you'd have to
> create something like that in every testing framework you'd like to
> use. Best would be to have it done at one place - e.g. in Watir.
> > Well, waiting should hopefully not break any compatibility - but
> potentially
> > slow some things down significantly. For example, an application that
> uses
> > watir that I work with  takes a string and (sometimes) checks if there is
> an
> > element with that id; if not checks if there is an element with that
> name;
> > then tries for label with that text. If each of those added a few
> seconds,
> > that'd be bad.
> My point was that it wouldn't break any backwards incompatibility nor
> slow down anything due to the fact that default timeout could be 0 as
> it currently practically is.
> I also have used similar solution to you by searching by multiple
> locators and allowing strings as a locator, but i've ditched it due to
> the possible problems (i wanted to find a different element, but ended
> up with something else due to some similar attribute) and actually
> making tests harder to read (of course it is a matter of taste). Also
> the main reason why i ditched that solution was due to the fact that
> it made tests considerably slower (what if you're always searching by
> something which is checked last?). That is especially true if some
> larger html pages with many elements are used.
> > I don't know. I think it's good functionality to have available, but I'm
> > getting more and more hesitant about the idea of changing the default to
> > wait any length of time - I do too much checking of maybe-nonexistent
> > elements in various places.
> So the only problem would remain if using some solution which allows a
> string as a locator and then searching by different locator types. You
> could in these methods to set timeout to 0 and after the method is
> done, revert the timeout back to it's original value so you wouldn't
> have to use wait_until's for "normal" checking for #exists? and
> such...
> So, in a light of this e-mail i see having only two additional methods
> - #not_exists? and #not_visible?. We could document then in RDoc
> properly to point out the differences between !exists? and
> not_exists?. I don't see any problems with that.
> With only these two changes it would be also quite easy to convert
> your existing test suites to work with a better way and remove many
> wait_until's by some global search & replace:
> !exists? => not_exists?
> not exists? => not_exists?
> !visible? => not_visible?
> not visible? => not_visible?
> I think that this is one of the functionalities where we'd have to
> make some compromises between adding two (could be little-bit
> confusing) methods + making tests a little more cleaner and using
> wait_until or something similar pretty heavily every here and there.
> I'm starting to like the former.
> 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
> with AJAX/JavaScript heavy sites where is a need to use wait_until or
> something similar).
> Jarmo
> _______________________________________________
> Wtr-development mailing list
> Wtr-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wtr-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wtr-development/attachments/20101019/1a172999/attachment-0001.html>

More information about the Wtr-development mailing list