Why we shouldn't use Thread.sleep()?

[Wen Bin, Soso Su]

       ok, I met many times when selenium-users say Thread.sleep() is not a good idea. it really confuse me, and I tried to find answers in google,but it seems not very helpful, can anyone answer me?
--
Soso

[Krishnan Mahadevan]

Soso,

IMHO, Thread.sleep() introduces a definite wait.

For e.g., if you were using Thread.sleep() and causing the current thread to always sleep for 20 seconds, then irrespective of anything your test would always wait for 20 seconds.

Now there are two sides of the story. 

There are always chances of your test taking more than 20 seconds to do some operation and you ending up trying to do the next action even when its not completed yet.

Then there are other times, when your action finished well in advance, but your test still waits for 20 seconds.

However, I have seen people circumvent this part, by having lower Thread.sleep() durations and then iterate within a loop for a max time before timing out.

Maybe others can chime in and provide different perspectives on why they feel "Stay away from Thread.sleep()" :)

Thanks & Regards
Krishnan Mahadevan

"All the desirable things in life are either illegal, expensive, fattening or in love with someone else!"

--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To post to this group, send email to seleniu...@googlegroups.com.
To unsubscribe from this group, send email to selenium-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/selenium-users?hl=en.

[Mark Collin]

Generally it is because Thread.sleep() will introduce a fixed period of inactivity no matter what happens which will slow down your test, and if you are using CI generally result in much longer test run times if used all over the place.

 

Secondly most people who use it end up doing so because they don’t understand a problem so it’s quick and easy to just throw in an arbitrary wait rather than trying to understand the problem and fix it. 

 

For example I perform an AJAX action and then have to wait for an element to appear, the correct thing to do would be to scan for the element until it appears and then carry on, but this is harder to code than to just throw in a 30 second wait so people use a Thread.sleep instead.  Now the problem is that this means you don’t really know why the test has failed if the element is not picked up after your 30 second time out, is it because the element didn’t appear at all, or is it because the AJAX call took longer than normal to return?  If you had some code that scanned for the element you could stick in a much longer timeout secure in the knowledge that you are not slowing your test down, and also secure in the knowledge that when it fails you can be sure that it is because the element didn’t return.

 

I’m sure people will argue that it is easier to use Thread.sleep and the difference in results as described above is not that great, but when you have 200 scripts getting run in CI and each one has about 5 Thread.sleeep calls you’ll see how much pain just throwing in a thread.sleep can cause.

-- This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify postm...@ardescosolutions.com

[Wen Bin, Soso Su]

 Thanks Krishnan and Marks, but in fact I have to use Thread.sleep()  frequent in my code, because my project often meet such question: for example
        selenium.type("");
        selenium.type("");      
        selenium.type("");
        selenium.click("name = button1");
 This code is record by selenium IDE, when I play it , error will occur, because selenium can't find button1, it's strange, and more strange is, when I add Thread.sleep() before click(), it works...so, why I often add Thread.sleep(500) is just because I want to let it stop a few milliseconds.

2011/8/26 Mark Collin <ma...@ardescosolutions.com>

--
Soso

[Mark Collin]

The correct way would be to wait for button1 to appear before continuing your test.  Did you actually read through what I wrote? J

[Ross Patterson]

Mark is right.  An additional problem with fixed waits like Java’s Thread.sleep() is that they work at the time you write the test and on the machine where you’re writing it.  Then the test gets run on a different machine, perhaps with less capacity, and the thing you’re actually trying to wait for takes longer to run.  But that means your pre-calculated wait isn’t long enough for that machine.

 

In my case, I have a REALLY nice laptop that can run our entire product stack (a typical multi-tier web application) and the tests, while doing a variety of other things.  It’s very fast, and very sweet J  But our tests also run on every code check-in, using virtual machines in Amazon’s EC2 cloud, and ran on VMware virtual machines before we switched to EC2.  Using waits the way Mark describes means that these tests behave reliably in this wide variety of environments, and also complete in the minimum possible time.  That’s important to us, because we run about 1200 of them each time, and it takes a total of about 15 hours (of course, we run lots of them in parallel).

 

Ross

[ChaotX]

An questions arrising about this topic and Im looking for an answer
for it:
When I use WebDriverWait on grid2 using RemoteWebDrivers, will the
grid timeout shut down the execution if I give longer timeout for the
actual WebDriverWait instance than the grid timeout?
And if grid wont shut it down (as I expect and understand why to use
webdriver wait) how can I anyway define a wait that wont trigger grid
timeout but is longer then that?
(this wait can be useful when trying to play with wire protocol and
need a remotewebdriver session ID maintained, or just to have it in
hand for worst case or asap scanarios)
I hope you understand my questions :)

[Mike]

While I agree completely that using a sleep to wait an arbitrary
amount so that you think something will complete in that time is a Bad
Thing, I will argue for a use for sleep.

I have code in my tests that do wait logic similar to the wait for an
element, but where I can't use that function because I am not waiting
for an element. In one case I am waiting for AJAX code to complete so
that I can log in. In that code I see if what I am waiting for has
occurred and if it has not I sleep for 1/10th of a second and try
again. By doing this I am being a good citizen and giving up the
machine so other code can run, instead of running around a loop as
fast as I can trying the same thing over and over again. This at
least gives other tasks a shot at doing useful work on the system
while I am waiting and if I happen to waste a whole 1/10th of a second
it is not big loss, but on average it would only be half of that.

So using Thread.sleep() is a double edged sword that can cut both
ways.

My $0.02 on it.

Mike

On Aug 26, 4:30 am, Ross Patterson <rpatter...@parature.com> wrote:
> Mark is right.  An additional problem with fixed waits like Java's Thread.sleep() is that they work at the time you write the test and on the machine where you're writing it.  Then the test gets run on a different machine, perhaps with less capacity, and the thing you're actually trying to wait for takes longer to run.  But that means your pre-calculated wait isn't long enough for that machine.
>

> In my case, I have a REALLY nice laptop that can run our entire product stack (a typical multi-tier web application) and the tests, while doing a variety of other things.  It's very fast, and very sweet :)  But our tests also run on every code check-in, using virtual machines in Amazon's EC2 cloud, and ran on VMware virtual machines before we switched to EC2.  Using waits the way Mark describes means that these tests behave reliably in this wide variety of environments, and also complete in the minimum possible time.  That's important to us, because we run about 1200 of them each time, and it takes a total of about 15 hours (of course, we run lots of them in parallel).
>
> Ross

[Mark Collin]

I would say that you are using it in exactly the right way the thing is that
most people will put in a 30 second wait to just "make it work" without
understanding why it works or what the implications of their code are.

My $0.02 on it.

Mike

--

[Raja sankar]

Instead of thread sleep use waitforcontidion in 1 or wait in 2. Using thread sleep makes the test broke and you will not doing any testing, will spend time in increasing or decreasing the sleep timings in your code.

Rajasankar

ராஜசங்கர்

[Michael Hashimoto]

A problem I see w/ using a "wait for" command every time is that sometimes that condition won't be fulfilled if say the xPath or identifier you are using changes.. assuming that your wait has a timeout of like 30 seconds then your test will pause 30 seconds instead of a set 5 seconds in your Pause.. so in that case the lesser of the 2 evils is a Thread.sleep()..  So I think you should make a judgement call on whether you use a pause or a "wait for"..  But I guess that also depends on how often your software changes..

Please chime in w/ thoughts about this.. I think this is an interesting question.

[PeterJef...@hotmail.co.uk]

If the software application doesn't provide any reliable condition
that you can test for other than using an unconditional and therefore
unreliable wait, then you need to go back to the software developers
and get them put in some sort of reliable condition state that you use
as the basis of the test.

In order for automated testing to get successfully implemented in an
organisation, it really needs to be done as part of the development
lifecycle and not as an afterthought. While the developers themsleves
should not necesarily be writing most of the tests, they should have
the responsibility to ensure that their application is testable by the
tools available.

On Aug 28, 8:32 am, Michael Hashimoto <mike.ha...@gmail.com> wrote:
> A problem I see w/ using a "wait for" command every time is that sometimes
> that condition won't be fulfilled if say the xPath or identifier you are
> using changes.. assuming that your wait has a timeout of like 30 seconds
> then your test will pause 30 seconds instead of a set 5 seconds in your
> Pause.. so in that case the lesser of the 2 evils is a Thread.sleep()..  So
> I think you should make a judgement call on whether you use a pause or a
> "wait for"..  But I guess that also depends on how often your software
> changes..
>
> Please chime in w/ thoughts about this.. I think this is an interesting
> question.
>

> On Sat, Aug 27, 2011 at 5:58 PM, Raja sankar <errajasankarc...@gmail.com>wrote:
>
>
>
> > Instead of thread sleep use waitforcontidion in 1 or wait in 2. Using
> > thread sleep makes the test broke and you will not doing any testing, will
> > spend time in increasing or decreasing the sleep timings in your code.
>
> > Rajasankar
>
> > ராஜசங்கர்
>

> >> postmas...@ardescosolutions.com

>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Selenium Users" group.
> >> To post to this group, send email to seleniu...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> selenium-user...@googlegroups.com.
> >> For more options, visit this group at
> >>http://groups.google.com/group/selenium-users?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Selenium Users" group.
> > To post to this group, send email to seleniu...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > selenium-user...@googlegroups.com.
> > For more options, visit this group at

> >http://groups.google.com/group/selenium-users?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Jose Sanchez]

Thread.sleep() should never be used for automation purposes because it
forces your code to wait a pre-defined amount of time, rather then
waiting the real-time it takes the application to wait for an object
or whatever it is. For example, you might set a thread.sleep(10) that
will wait 10 seconds for something to appear, but if it shows up on
the page within 3 seconds, it will still have to wait 7 seconds,
wasting precious time in your test sleeping. If for no other reason,
there are better ways with the selenium API to wait for elements.

[Ramesh A]

Apart from that,  It would slow down your automation speed too and make ur automation time to go for a longer time.  This includes performing actions like click, type, open, etc


--
With Cheers & Regards
Ramesh

"Pleasure in the job puts perfection in the work."

--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To post to this group, send email to seleniu...@googlegroups.com.
To unsubscribe from this group, send email to selenium-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/selenium-users?hl=en.

--
With Cheers & Regards
Ramesh

"Pleasure in the job puts perfection in the work."

[Mark Collin]

Your scenario is contrived and seems to be a way to justify the usage of Thread.sleep().  If you need to wait for up to 5 seconds set your wait to wait for 5 seconds, that way it will only wait for up to 5 seconds before failing. 

 

In the screnario you describe Thread.Sleep() is still the wrong way to do it, Thread.sleep() is not the lesser of two evils, it is just a lazy way of makings things work rather then analysing the problem, understanding the problem and then fixing the problem.

 

From: seleniu...@googlegroups.com [mailto:seleniu...@googlegroups.com] On Behalf Of Michael Hashimoto

Sent: 28 August 2011 08:33
To: seleniu...@googlegroups.com

[Ross Patterson]

Yes, this is the only really valid use of a fixed-duration wait - to implement a wait-for-something-appropriate-to-happen method, typically using a loop with a max-1-second wait. We have several of these that we've written ourselves, including a really weird one that waits for a JavaScript WYSIWYG editor to load and initialize itself, which can take several seconds of run time plus downloading a bunch of visual elements. And, of course, all of Selenium's built-in waits are done this way.

Ross

-----Original Message-----
From: seleniu...@googlegroups.com [mailto:seleniu...@googlegroups.com] On Behalf Of Mike
Sent: Friday, August 26, 2011 11:29 AM
To: Selenium Users

[Ross Patterson]

If the wait-for-condition would timeout because the XPath or ID has changed, then the test deserves to fail.  In this case, either the application or the test is brittle, and the test will probably fail from time to time even when the application is verifiably correct.  The only thing worse than not having a test is having a test that fails or passes when it should do otherwise.

 

The way around this is to find a 100% reliable wait-for condition, not to insert fixed-duration waits, and to fail as fast as possible, not to cruise on hoping for success.

 

Ross

[nvaka...@gmail.com]

On Friday, August 26, 2011 at 9:00:49 AM UTC+5:30, Krishnan Mahadevan wrote:

Soso,

IMHO, Thread.sleep() introduces a definite wait.

For e.g., if you were using Thread.sleep() and causing the current thread to always sleep for 20 seconds, then irrespective of anything your test would always wait for 20 seconds.

Now there are two sides of the story. 

There are always chances of your test taking more than 20 seconds to do some operation and you ending up trying to do the next action even when its not completed yet.

Then there are other times, when your action finished well in advance, but your test still waits for 20 seconds.

However, I have seen people circumvent this part, by having lower Thread.sleep() durations and then iterate within a loop for a max time before timing out.

Maybe others can chime in and provide different perspectives on why they feel "Stay away from Thread.sleep()" :)

Thanks & Regards
Krishnan Mahadevan

"All the desirable things in life are either illegal, expensive, fattening or in love with someone else!"

@Mr. KRISHNA MADHAVAN- Sir could make it simple, I mean an explination  in simple words.

[Gary @ Qarbon]

Hi,

There is lots of good advice here and I am definitely in the camp of "avoid waits at all costs if you can".

My best advice is "humanise your scripts and make them intelligent" - if I was trying to test a web site, would I blindly try to click before the button has appeared? Would I spot the button has appeared and then wait several more seconds before clicking it? Of course not. Adding a wait of say 500 ms is a bit like, wearing a blindfold as a human tester and then clicking after the time is up regardless of the application state.

Don't be fooled by recording utilities which simply record a sequence of actions. Make use of WebDriver functions that wait for states like enabled and clickable. Then click. If this is too much effort, write wrapper functions that perform these actions before the click automatically and then insert such function calls into your scripts.

The more sophisticated and often expensive automation tools, even from the mid 90's (the WinRunners and QTP's of the day), effectively did this for you. A recorded click was replayed with such intelligence. By the way, I am using the example of a simple button click but you need to apply such intellgence to many other types of operations too.

In my long experience, lack of intelligent synchronization discredits and kills many automation efforts. It is worth the effort in the long run. And don't forget to factor this into any estimates for automating existing manual tests.

Regards

Gary

[Philip Lonsing]

This article might be interesting for you:

How to write reliable browser tests using Selenium and Node.js

https://medium.freecodecamp.org/how-to-write-reliable-browser-tests-using-selenium-and-node-js-c3fdafdca2a9