It's a thorny issue. in the 'old days' most automation apps I used
had a wait/timeout parameter on nearly every action you could take,
and it was needed because very often a UI would get slow in places or
there were times that background processing was happening. Staying
'synced up' with the UI was a big issue and someone hoping to make any
effective use of a tool like winrunner had to learn how to do that.
In the web 1.0 era this was not nearly so big of an issue because you
could basically just wait till the browser was done loading the page,
and go on with the script. Watir was designed in this era and thus (I
believe) there was no thought to having a consistent way to 'wait for
things to be right'. Simply waiting for the browser to finish loading
the page was all you needed to do, and Watir is designed around this.
In the web 2.0+ era we are seeing more and more pages that load and do
things in an async manner, or have huge amounts of client side code
that runs as/after the page loads to put it in the proper form,
perform CSS magic, set element states like hidden/displayed/enabled,
relocate stuff on the screen etc. In addition we have a lot of client
side code such as many functions availble via Jquery and 3rd party
tools that interact directly with the webserver and refresh partial
portions of the page __without__ doing a page load. All of this makes
waiting and 'syncing' to the UI an issue again on a lot of sites where
these things are happening and you have one of two situations
1) the page is NOT ready the instant that the browser finishes
pulling data from the server, and needs a moment to process client
side code
2) Data is fetched and the page updated by client side code and the
browser never goes into a 'loading' mode, and again time is needed for
the data to be retrieved and portions of the page to re-render.
The global implicit wait is thus a very tempting solution for someone
faced with a lot of timing issues due to modern client side heavy web
page design. I can understand the attraction. Although I have to
agree that it opens up a pretty big 'can of worms' as it were and has
a downside. The problem is that the alternative of constantly having
to invoke tactics from 'how to wait with watir' is somewhat
cumbersome, and with a 1 second granularity can cause a a significant
aggregate increase in execution time for scripts when there is a lot
of waiting needed. and unless I'm confused, if you COMBINE implicit
and explicit waits, then you may be faced with a multipler effect
where a loop you intended to wait 10 seconds, if run with a 5 second
implicit wait, ends up waiting 50 seconds.
We've been dealing with it in a sort of as needed patchwork way,
implementing a few methods with concepts like 'when present' but that
solution is also a bit cumbersome. It causes me to wonder if for a
2.5 or 3.0 version of the api we need to add the idea of an additional
parameter on most methods that would be a wait time (and have it
default to zero if not present), or if we would need to create
'_when_present' varients for nearly all methods/objects
In the meantime, the best recommendation I can make is for people to
work with their devs to make this kind of thing easier to test. What
I've found to work is some kind of handy semiphore that can be used to
tell when client side code is waiting, and when the page is ready. In
this respect, I recommend the use of a 'working/loading' graphic
(usually an animated image) that is displayed first thing hidden
last thing, whenever client side code is running. If this element has
the same ID (or it's in a container with a consistent ID) then that
makes it very easy to create a method that waits for that element to
go to a hidden state and just call that method whenever you know you
need to wait for client side code to finish doing its thing. You can
have your method take a parameter which is a 'number of seconds to
wait' use a loop with a 1 second sleep, that exits once the element is
in the hidden state or the max loop count reached.
On Oct 9, 10:17 am, Jarmo Pertman jarm...@gmail.com wrote:
I'd have to agree with Jari on this.
Jarmo Pertman
-
IT does really matter -http://itreallymatters.net
On Oct 5, 2:43 pm, Jari Bakken jari.bak...@gmail.com wrote:
I usually prefer waiting explicitly (especially since watir-webdriver makes
it so easy) and never use implicit waits. Implicit waits hide information
about app behaviour from test developers that I think is often quite
relevant, and slows down your tests when (a) you want to check that an
element is missing or (b) the missing element is an application bug and
should fail immediately.
It'd be useful if the waiting page on the web site could separate a bit
between the two approaches. Combining them is not always pleasant, see
e.g.https://groups.google.com/forum/#!topic/selenium-developers/91vSZHxAnCg
Jari
On Wed, Oct 5, 2011 at 1:27 PM, Alister Scott
