What will you learn in this course?
Are you struggling with working with HTML using Selenium WebDriver? Do you know how to easily identify and manipulate an element using Selenium WebDriver? How about performing a drag n’ drop on an element? If not, then these are just a few of the questions that will be answered in this course.
This course is a complete guide on working with web elements in Selenium WebDriver! Once you are finished with this course, you will know how to work with any web elements, anytime, on any web application.
In this course from Ultimate QA, you will learn:
– Basics of HTML
– All the different locator strategies for Selenium WebDriver
– How to identify web elements using Selenium WebDriver
– Master XPath
– Navigation with Selenium WebDriver
– Web element manipulation
– Web element interrogation
– Mouse and keyboard actions with Selenium WebDriver
– Performing actions such as drag n’ drop, drawing, hovering
– Implicit and Explicit waits
– How to properly handle element identification so that your tests are not flaky
– Expected Conditions in Selenium WebDriver
What will you learn in this lecture?
In this video, we will go through the disadvantage of an implicit wait 1 of the Implicit and Explicit Waits course.
Selenium Tutorial – Implicit and Explicit Waits Answer Disadvantage of an implicit wait 1
Now I did want to give you guys a word of caution regarding implicit waits. Now 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 and the disadvantages are paramount to understanding the difference between an implicit waits and the other different kinds of waits that selenium web driver provides for us. So one of the disadvantages regarding a selenium waits selenium inputs it’s waits is that it can extend the runtime of our tests. Now imagine with me an application that goes from death to tell so proud. Right.
A standard process.
And so we have our application here on dev and then the application goes to test and then it goes to prod a good and wise Q 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. So we’re going to set it to five seconds to make sure that all of the elements are loading so that whenever we’re tracking for them that they are here and all of our tests pass Horray.
Now we move that application to test and we don’t change the code.
We rerun it and everything continues working. And then we finally move it to prod Horray. Everything is working fine and we left our implicit way time out of five seconds. So what is the problem that we have just caused. Well Dev is usually much slower than production because production is used to support tens of thousands or hundreds of thousands of users. Hitting the applications so it probably has many load balancers many servers supporting this production environment while dev just needs a few developers to be hitting the application. Test may be a little bit more if we’re lucky our tests will mimic Prod. but sometimes it doesn’t. So because production is much before usually the application performs much better. Therefore we are actually slowing down our test cases because they may not need to be polling for 5 seconds for every single element. Let me show you what I mean here. Imagine this application right 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 to the server to fetch your content pull the content back. That part usually takes a little bit longer than fetching the rest of the content. So if we’re transitioning from page to page yes we need a implicit wait five seconds to be able to wait for the next element. Right if I was validating that this image is present here. Five seconds is probably sufficient to check that it’s there.
But now if I want to interact with one of these other elements I probably should not be waiting for 5 seconds to see if their present. I should probably be waiting for one two seconds maximum because if this page is loaded and this element is present right here I don’t need to be waiting for 5 seconds for these elements. Or even worse if your application is really slow and sometimes yes. I have taken my implicit way timeouts through 30 or a minute. So now imagine this page loads and this image is present but for whatever reason this button doesn’t exist or this image doesn’t exist and you’re sitting and waiting for it for 30 seconds or a minute to come up before actually failing the test. That is a lot of wasted time and of course you’re going to have many tests that do these kinds of checks and now because there is a bug in the code you’re going to be sitting and waiting for this element for 30 seconds before knowing that a test has actually failed. When instead you probably should have waited much less so that’s what I mean it can actually make your test slower when it comes to actually finding failures is going to significantly slow you down because it is going to wait for that duration of time for the element until it is no longer on the page and then times out and so what are you going to do. Are you going to write another implicitly wait statement to decrease that time. Here to deal with these elements. And so you’re going to decrease it to what 2 seconds. But remember that’s for the duration of the lifespan of the driver.
So now at every single point in your test whenever you’re ready to deal with a different kind of weight you need to write a new implicit wait statement and then you need to be able to manage that implicit weights to know how long it is where it was set and be able to set it and reset it appropriately so that your test is working well.