In This Course
In this course, you will:
1. Learn the problems that can occur as a result of improper synchronization
2. Learn how to use Selenium Webdriver explicit waits
3. Master Selenium Webdriver implicit wait
4. Understand what a DefaultWait is
5. Comprehend how to use all of the different types of waits during appropriate situations
In this Lecture
This discussion talks about the disadvantage of an implicit wait, which extending the run time on tests. It helps you understand why such a disadvantage occurs and what you can do when doing your tests. These disadvantages can help you in understanding the differences between other waits.
Selenium Tutorial – Disadvantages of an Implicit Wait I
I did want to give you a word of caution regarding implicit waits. Don’t worry I didn’t forget about the disadvantages. Remember I said, I was going to talk about them and now we are going to discuss those.
This disadvantages are paramount to understanding the difference between an implicit wait and the other kinds of wait that Selenium WebDriver provides for us. One of the disadvantages regarding a Selenium implicit wait is that it can extend the run time of our tests.
Imagine with me, an application that goes from dev, to test to prod, a standard process. We have our application here on dev, then the application goes through test and then it goes to prod. A good and wise QA Engineer will write a test here and our test is going to wait for five seconds, using an implicit wait because our application is a little bit slower here. We are going to set it to five seconds to make sure that all of the elements are loading so whenever we are checking on them that they appear and all of our tests passed. Hurray!
Now we move that application to test and we don’t change the code, we re-run it and everything continues working. Then we finally moved it into prod. Hurray! Everything is working fine. We left are implicit timeout of five seconds.
What is the problem that we have caused?
Dev is much slower than production because production is used to support tens of thousands or hundreds of thousands of users hitting the application so it probably has load balancers, many servers, supporting this production environment While Dev, just needs a few developers to be hitting the application.
Test maybe a little bit more. If we are lucky, our test will mimic prod but sometimes it doesn’t. Because production is much beefer usually the application performs much better. Therefore, we are actually slowing down our test cases because they may not be polling for five seconds for every single element.
Let me show you what I mean here
Imagine this application and it loads in a certain period of time. You can see that it takes a certain period of time for the application to actually load. The elements themselves don’t take that long to load. It’s the actual traffic to go through the server, to fetch the content, to pool the content back. That part usually takes a little bit longer than fetching than the rest of the content.
If we are transitioning from page to page, we need an implicit wait of five seconds to be able to wait for the next element. If I was validating that this image is present here, five seconds is probably sufficient to check that it is there. If I want to interact with one of these other elements, I probably should not be waiting for five seconds to see if they are present. I probably should be waiting for one or two seconds maximum because if this page is loaded and this element is present right here, I don’t need to be waiting for five seconds for these elements.
Worst Case Scenario
Even worse, if your application is really slow and sometimes yes, I have taken my implicit wait time out to thirty or a minute. Imagine, if this page loads and this image is present but for whatever reason this bug doesn’t exist or this image doesn’t exist and you are sitting and waiting for it for thirty seconds or a minute to come up before actually failing the test that is a lot of wasted time.
Of course, you are going to have many tests that do these kinds of checks. Because there was a bug in the code, you are going to be sitting and waiting for this element for thirty seconds before knowing that a test has actually failed. When instead, you probably have waited much less. That’s what I mean, it can actually make your test slower. When it comes to finding failures, it’s going to slow you down because it’s going to wait for that duration of time for the element until it is no longer on the page and then times out.
What are you going to do?
Are you going to write another implicitly wait statement to decrease the time here to deal with these elements? You are going to decrease to what, two seconds?
Remember, that’s for the duration of the lifespan of the driver. At every single point in your test, whenever you are ready to the different kinds of wait, you need to write a new implicit wait statement. Then you need to be able to manage that implicit wait to know how long it is, where it was set and be able to set and reset it appropriately so that your test is working well.
Nikolay Advolodkin is a self-driven SDET on a lifelong mission to create profound change in the IT world and ultimately leave a legacy for his loved ones, community, and the world at large. Today, he serves as the CEO and Test Automation Instructor at UltimateQA.com and contributes informative articles to leading test automaton websites like SimpleProgrammer.com and TechBeacon.com