Article content
A simple search in our test automation repository for "Thread.Sleep" returns over 600 instances in just the baseline regression suite alone. With an average of 10 seconds per instance, nearly 2 hours of wait time induced by using Thread.Sleep() alone. By enabling high reuse in the test automation code, this wait time could inherently be exponentially higher.
While I understand the intent and accept the need for waits in test scripts, shouldn’t these be replaced with smarter wait handlers such as explicit or fluent waits? It will definitely reduce the overall execution time.
Is it convenience or ignorance driving this behavior among test engineers? What are your thoughts?
Inspired from
- https://blogs.msmvps.com/peterritchie/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program/
- https://saucelabs.com/blog/how-to-avoid-threadsleep-in-test-automation
- https://www.seleniumhq.org/docs/04_webdriver_advanced.jsp#explicit-and-implicit-waits
If you found this interesting, you can find more such articles here on quality assurance, test automation, tools, and processes. Don't forget to like and share this post with friends and community. If you have a question, connect with me through the contact form. Thank you!
