[Wtr-development] automatic waiting?

Jarmo jarmo.p at gmail.com
Tue Oct 19 16:03:10 EDT 2010

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

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).


More information about the Wtr-development mailing list