[Wtr-development] automatic waiting?

Ethan notethan at gmail.com
Sun Oct 17 21:10:24 EDT 2010

I've also been thinking about implementing that too. The downside is slowing
things down significantly when something goes wrong, or when debugging -
sitting around waiting for error messages to finally show up is annoying. I
think it'd be good, provided two things.

1. it's configurable, so users can turn it off or adjust the amount of time
it waits.
2. the default is short, not more than one second. waiting 5 seconds in irb
whenever I try to access a nonexistent element would annoy me a lot. 1
second is plenty of time for javascript that doesn't interact with a server.
it's not enough for AJAX stuff, but the user can set this to longer as
needed, or use an explicit wait_until.

I also think that this should happen in #initialize, and not in
#assert_exists - it should only happen once at the beginning, not whenever
you try to do anything with an element. that conflicts with watir's lazy
locating, though. I think that should change too, personally - just seeing
'located=false' when inspecting an element is not useful. (vapir tries to
locate in #initialize and shows 'exists?=false' on elements that don't
exist, doesn't ever just say "I don't know, I haven't tried to find it


On Sun, Oct 17, 2010 at 08:21, Alister Scott <alister.scott at gmail.com>wrote:

> I'd personally be all for it.
> I am currently having the same problem you've described testing an
> AJAX heavy app, and I have a lot of waits of up to 50 iterations of
> 0.2 seconds sleep (max 10 seconds wait).
> Something like you described would make my job a lot easier.
> Cheers,
> Alister Scott
> Brisbane, Australia
> Watir Wiki Master: http://watir.com
> Blog: http://watirmelon.com
> Google: http://www.google.com/profiles/alister.scott
> LinkedIn: http://www.linkedin.com/in/alisterscott
> On 17/10/2010, at 10:15 PM, Jarmo <jarmo.p at gmail.com> wrote:
> > Hi!
> >
> > I have been thinking about making Watir wait automatically before
> > throwing Exceptions. I don't know how you are dealing currently with
> > the pages with Ajax/JavaScript usage, but i find myself quite often
> > using some wait_until or similar solution. It has happened quite often
> > that i create a test and it's ok, but then at some CI machine it fails
> > intermittently and i end up inserting some wait_until in between
> > assertions or anything else.
> >
> > The problem is that sometimes JavaScript is used to redirect/refresh
> > or change the DOM. All these things are not blocking #wait if i'm not
> > mistaken. If JavaScript redirect/refresh is used then there is a
> > possibility that there will be some random errors because Watir loads
> > the page and thinks everything is ready and doesn't block in #wait
> > anymore, but right then the redirect is issued and something might
> > break or might not break - depending of the timing.
> >
> > So, i was thinking - why not add some 5-10 seconds wait_until into
> > somewhere to not throw Exception right away if the object doesn't
> > exist? Or if the object isn't visible? So, if the test is failing then
> > it waits maximum of 5-10 seconds befor actually failing and if test is
> > ok, then it doesn't add any extra waiting time. And there's no need to
> > put all those wait_until's into every here and there. If there's some
> > longer Ajax call or anything then you can still use a wait_until in
> > your test with longer timeout. So it shouldn't break any backwards
> > compatibility either.
> >
> > What do you guys think? Is there any reason why not to implement
> > something like that?
> >
> > Jarmo
> > _______________________________________________
> > Wtr-development mailing list
> > Wtr-development at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wtr-development
> _______________________________________________
> 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/20101017/fe090acd/attachment.html>

More information about the Wtr-development mailing list