[Wtr-development] automatic waiting?

Ethan notethan at gmail.com
Tue Oct 19 14:26:49 EDT 2010

On Tue, Oct 19, 2010 at 13:05, Jarmo <jarmo.p at gmail.com> wrote:

> After given some more thought then there's a possibility to create
> dynamically some negative case methods like not_exists? for exists?
> and not_visible? for visible? and so on so it would be possible to
> wait some time for that condition to happen.
> This means you could do in Test::Unit
> assert div.not_exists?
> instead of
> assert !div.exists?
> With RSpec you'd have to use a slightly different syntax than usually:
> div.should not_exist # (normally you'd use div.should_not exist)

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.

> But still the case:
> wait_until {div.text == "something"}
> doesn't have any solutions at all... one solution would make some
> #has_(no)_text?(text) method(s) on browser/element classes to support
> that and some other's too like #has_(no)_class?(css_class) and so
> on... i don't think that there's actually too many methods which might
> need these solutions.

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

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

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.

We could roll that functionality out without breaking any backwards
> compatibility by having that timeout configured as 0 - e.g. don't
> wait...

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.

Then it could be possible to set that timeout to let's say 2 seconds
> and you could use "div.should exist" which would wait maximum of 2
> seconds before failing if the div doesn't exist. If div exists then it
> will take as much time as it is taking now.
> In the future we could start displaying deprecation warnings if
> timeout stays at 0 - this means that users are not taking advantage of
> that automatic waiting feature and after few versions we could set
> that timeout to something else than 0 by default.

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, in short, there could be a way to ease some of the current pain by
> creating dynamically or not dynamically the negative counterparts to
> current "boolean" methods.
> I think that #exists? and #visible? are the most used with wait_until...
> What do you guys think about that not-so-perfect-solution? Do you have
> any better ideas?
> 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/76994109/attachment-0001.html>

More information about the Wtr-development mailing list